Widok sys.parameters

sys.parameters zwraca listę parametrów zdefiniowanych dla procedur i funkcji w bazie.

Widok sys.parameters — czym jest i do czego służy

Widok sys.parameters jest systemowym źródłem informacji o parametrach przypisanych do procedur składowanych oraz funkcji zapisanych w bazie danych. Pozwala sprawdzić, jakie argumenty przyjmuje konkretna procedura lub funkcja, w jakiej kolejności należy je przekazać, jaki mają typ danych oraz czy dany parametr pełni rolę wejściową, wyjściową albo łączy obie funkcje. Dzięki temu można analizować strukturę obiektów bez przeglądania całego kodu źródłowego i bez zgadywania, jakie wartości powinny zostać użyte podczas wywołania.

Informacje zwracane przez ten widok są szczególnie przydatne podczas pracy z bazą, w której istnieje wiele procedur i funkcji tworzonych w różnych momentach. Parametry stanowią kontrakt pomiędzy obiektem programowalnym a instrukcją, która go uruchamia. Jeżeli kontrakt zostanie odczytany nieprawidłowo, mogą pojawić się błędy konwersji typów, brak wymaganej wartości, niezgodność kolejności argumentów albo nieoczekiwane wyniki. Odczyt danych z sys.parameters pomaga uporządkować tę wiedzę.

Widok może być wykorzystywany zarówno do jednorazowej diagnostyki, jak i do tworzenia narzędzi administracyjnych. Na jego podstawie można przygotować zestawienie parametrów wybranego obiektu, porównać wersję procedury przed i po zmianie, wygenerować dokumentację techniczną albo sprawdzić, czy aplikacja przekazuje argumenty zgodne z aktualną definicją. W praktyce jest to jeden z elementów katalogu systemowego, który ułatwia rozpoznanie budowy bazy na podstawie metadanych.

Widok sys.parameters a kontekst techniczny i porównanie z innymi źródłami

sys.parameters opisuje parametry należące do procedur składowanych i funkcji, ale nie należy utożsamiać go z pełnym tekstem definicji obiektu. Widok pokazuje informacje katalogowe, natomiast kod instrukcji można analizować za pomocą innych widoków i funkcji systemowych przeznaczonych do odczytu definicji. W rezultacie oba rodzaje danych uzupełniają się: jeden opisuje interfejs obiektu, a drugi pokazuje sposób działania zapisany w jego treści.

Warto odróżnić parametry od kolumn zwracanych przez funkcję tabelaryczną. Parametr jest wartością przekazywaną do obiektu lub zwracaną przez niego jako argument wyjściowy. Kolumna wyniku należy natomiast do zestawu danych generowanego przez funkcję. W przypadku funkcji tabelarycznej sama lista parametrów nie odpowiada więc wszystkim informacjom potrzebnym do poznania kształtu zwracanego wyniku. Podobnie parametry procedury nie są tym samym co kolumny tabeli odczytywanej przez procedurę.

Przy interpretowaniu metadanych przydatne jest zestawienie sys.parameters z widokiem sys.objects albo sys.procedures. Takie połączenie pozwala ustalić, do jakiego obiektu należy dany parametr, jaki jest typ obiektu oraz czy obiekt jest procedurą, funkcją skalarną czy funkcją tabelaryczną. Informacje o typach danych można dodatkowo powiązać z katalogiem typów systemowych, aby uzyskać nazwę typu, jego długość, precyzję i skalę.

Podstawą identyfikacji jest zazwyczaj kolumna object_id. Dzięki niej można połączyć rekord parametru z rekordem procedury lub funkcji. Kolejność argumentów odczytuje się z numeru porządkowego parametru, a jego nazwę z odpowiedniej kolumny metadanych. W ten sposób można zbudować czytelny opis przypominający deklarację obiektu, nawet jeżeli osoba analizująca bazę nie ma dostępu do dokumentacji przygotowanej przez autora.

• object_id wskazuje obiekt, do którego należy parametr;
• name przechowuje nazwę parametru, jeżeli została nadana;
• parameter_id określa pozycję parametru w deklaracji;
• system_type_id i user_type_id pomagają rozpoznać typ systemowy lub typ zdefiniowany przez użytkownika;
• max_length, precision oraz scale opisują właściwości przechowywanych wartości;
• znaczniki dotyczące kierunku parametru wskazują, czy argument może zwracać wartość na zewnątrz.

Widok sys.parameters — typowe problemy podczas odczytu

Jednym z częstszych problemów jest analizowanie parametrów bez uwzględnienia kontekstu bazy danych. Widoki katalogowe pokazują obiekty dostępne w określonej bazie i w zakresie uprawnień użytkownika wykonującego zapytanie. Jeżeli połączenie wskazuje inną bazę albo konto nie ma prawa odczytu odpowiednich metadanych, wynik może być pusty lub niepełny. Taki rezultat nie musi oznaczać, że procedura nie ma parametrów albo że obiekt nie istnieje.

Trudności może powodować również rozróżnienie typu systemowego i typu zdefiniowanego przez użytkownika. Sam identyfikator typu nie zawsze jest wystarczający do przygotowania czytelnej dokumentacji. Należy sprawdzić, czy parametr wykorzystuje typ wbudowany, aliasowy, typ tabelaryczny lub inną konstrukcję wspieraną przez daną wersję systemu. W szczególności typy o zmiennej długości wymagają poprawnej interpretacji wartości opisującej rozmiar.

Osobnej uwagi wymaga parametr typu tabelarycznego. Jego opis może obejmować dodatkowe informacje, których nie da się przedstawić wyłącznie jako nazwy prostego typu danych. Do odtworzenia struktury takiego parametru trzeba sprawdzić powiązany typ tabelaryczny, jego kolumny, typy kolumn oraz ewentualne ograniczenia. Samo odczytanie nazwy parametru może prowadzić do zbyt ogólnego opisu.

Inny problem pojawia się po zmianie procedury lub funkcji. Metadane mogą być odczytywane poprawnie, lecz aplikacja, skrypt albo dokumentacja nadal mogą używać wcześniejszej wersji deklaracji. Zmiana nazwy, kolejności, typu lub kierunku parametru powinna więc być analizowana razem z miejscami, w których obiekt jest wywoływany. Szczególną ostrożność należy zachować przy zmianach kolejności, ponieważ wywołanie pozycyjne może przekazać poprawnie wyglądające wartości do niewłaściwych argumentów.

Nie zawsze można też oczekiwać, że nazwy parametrów będą opisowe. W starszych obiektach mogą występować skróty, nazwy techniczne albo brak nazwy. W takim przypadku znaczenie argumentu trzeba ustalić na podstawie deklaracji, kodu procedury, użycia w zapytaniach oraz dokumentacji aplikacji. Metadane pokazują strukturę, ale nie zawsze wyjaśniają intencję autora.

Widok sys.parameters — praktyczne wskazówki do zapytań i dokumentacji

Najbezpieczniej rozpocząć analizę od znalezienia identyfikatora obiektu, a następnie pobrać parametry posortowane według numeru porządkowego. Sortowanie jest ważne, ponieważ kolejność zwróconych wierszy bez jawnego ORDER BY nie powinna być traktowana jako gwarantowana. W zestawieniu warto umieścić nazwę obiektu, nazwę parametru, numer pozycji, typ danych oraz informacje o długości, precyzji i skali.

Przykładowy schemat zapytania może wyglądać następująco:

SELECT p.object_id, p.parameter_id, p.name, t.name AS type_name, p.max_length, p.precision, p.scale
FROM sys.parameters AS p
JOIN sys.types AS t ON p.user_type_id = t.user_type_id
WHERE p.object_id = OBJECT_ID(N'dbo.NazwaObiektu')
ORDER BY p.parameter_id;

W rzeczywistym użyciu warto doprecyzować warunek łączenia typów, zwłaszcza gdy w bazie występują typy użytkownika o tej samej nazwie lub typy o podobnych właściwościach. Dobrą praktyką jest również uwzględnienie schematu obiektu. Funkcja OBJECT_ID powinna otrzymywać pełną nazwę, ponieważ sama nazwa bez schematu może wskazać nie ten obiekt, który był przedmiotem analizy.

Jeżeli celem jest dokumentacja, można wygenerować dla każdego obiektu deklarację w postaci: nazwa parametru, typ, właściwości rozmiaru oraz informacja o parametrze wyjściowym. Taki opis należy jednak traktować jako wynik metadanych, a nie jako automatycznie kompletną instrukcję wywołania. Trzeba jeszcze uwzględnić wartości domyślne, reguły walidacji zapisane w kodzie, zależności pomiędzy argumentami oraz możliwe wartości specjalne.

Podczas porównywania dwóch środowisk przydatne jest zestawienie wyników po nazwie obiektu i numerze parametru. Należy sprawdzać nie tylko liczbę parametrów, lecz także ich typy, długości, kierunek oraz kolejność. Dzięki temu można wykryć różnice, które nie są widoczne przy pobieżnym porównaniu samej nazwy procedury. Taka kontrola sprawdza się przed wdrożeniem zmian, po odtworzeniu bazy z kopii oraz podczas porządkowania starszych obiektów.

Widok sys.parameters — kiedy zgłosić się do serwisu

Problemy z odczytem sys.parameters często wynikają nie z samego widoku, lecz z konfiguracji komputera, uszkodzonej instalacji narzędzia bazodanowego, błędów połączenia, nieprawidłowych uprawnień albo problemów z systemem plików. Jeżeli nie można połączyć się z bazą, aplikacja przestaje widzieć procedury, zapytania kończą się błędami albo komputer działa niestabilnie podczas pracy z danymi, potrzebna może być pomoc techniczna przy laptopie lub komputerze stacjonarnym.

W takich sytuacjach Warszawskie Pogotowie Komputerowe 24/7 zajmuje się diagnostyką sprzętu i problemów związanych z działaniem oprogramowania, z uwzględnieniem bezpiecznego postępowania z danymi użytkownika. Przed rozpoczęciem prac można przygotować nazwę bazy, komunikat błędu, wersję używanego programu oraz informację, czy problem występuje przy jednym obiekcie, czy przy całym połączeniu. Takie dane ułatwiają odtworzenie sytuacji i ograniczają ryzyko przypadkowej zmiany konfiguracji.

Nie powinno się usuwać procedur, modyfikować uprawnień ani zmieniać definicji parametrów wyłącznie na podstawie pojedynczego pustego wyniku. Najpierw warto potwierdzić właściwą bazę, konto, schemat i nazwę obiektu, a także sprawdzić, czy problem dotyczy narzędzia, połączenia czy samej bazy. Dopiero po zebraniu tych informacji można bezpiecznie zaplanować dalsze działania. W przypadku ważnych danych zalecane jest wykonanie sprawdzonej kopii przed zmianami w strukturze obiektów.