Parametry wejściowe

Parametry wejściowe to wartości przekazywane do procedury w momencie jej wywołania.

Jak parametry wchodzą do procedury składowanej

W SQL Server parametry deklaruje się zaraz po nazwie procedury, poprzedzone znakiem małpy, z jawnie podanym typem: CREATE PROCEDURE dbo.RaportSprzedazy @DataOd date, @DataDo date, @IdKontrahenta int = NULL. Wartość domyślna po znaku równości sprawia, że parametr staje się opcjonalny. Przy wywołaniu można podać argumenty w kolejności deklaracji albo, bezpieczniej, nazwami: EXEC dbo.RaportSprzedazy @DataOd = '2026-01-01', @DataDo = '2026-01-31'. Parametr oznaczony słowem OUTPUT działa w drugą stronę i zwraca wartość do zmiennej wywołującego, co jest wygodniejsze niż zwracanie jednowierszowego zbioru wyników.

Typ parametru decyduje o wydajności całego zapytania

Najczęściej niedoceniana pułapka to niezgodność typów. Jeśli kolumna w tabeli ma typ varchar, a parametr zadeklarowano jako nvarchar, serwer musi wykonać konwersję po stronie kolumny i przestaje korzystać z indeksu — zapytanie, które powinno trwać milisekundy, przechodzi w pełne skanowanie tabeli. Podobnie działa zbyt krótka deklaracja długości tekstu, ucinająca argument bez ostrzeżenia. Osobne zjawisko to podglądanie wartości parametru przy pierwszym wykonaniu: plan zapytania zostaje zbudowany pod tę jedną wartość i zapamiętany, więc procedura szybka dla wąskiego zakresu dat potrafi zamulić przy zakresie rocznym. Zaradza temu wskazówka OPTION (RECOMPILE) albo przepisanie wartości do zmiennej lokalnej.

Parametryzacja jako zabezpieczenie przed wstrzyknięciem kodu

Największa wartość parametrów nie leży w wygodzie, tylko w bezpieczeństwie. Sklejanie zapytania z tekstu wpisanego przez użytkownika otwiera drogę do wstrzyknięcia SQL, bo apostrof w polu formularza zamyka literał i pozwala dopisać własne polecenie. Przekazanie tej samej wartości jako parametr do sp_executesql sprawia, że silnik traktuje ją wyłącznie jako daną, nigdy jako kod. Warto pilnować tego również wewnątrz procedur budujących zapytania dynamiczne, bo tam problem wraca tylnymi drzwiami. Uzupełnieniem jest walidacja po stronie procedury: sprawdzenie zakresu dat, odrzucenie wartości ujemnych i zwrócenie czytelnego komunikatu przez RAISERROR albo THROW zamiast pozwalania na błąd konwersji.

Diagnostyka wolnych raportów w programach handlowych

Zgłoszenia brzmią zwykle tak samo: raport, który generował się kilkanaście sekund, nagle zajmuje kilka minut. Analizujemy wtedy plany wykonania procedur w bazach Subiekta, WAPRO i systemów Comarch, sprawdzamy zgodność typów parametrów z kolumnami, stan statystyk i fragmentację indeksów. Często wystarczy odświeżenie statystyk i poprawienie jednej deklaracji, żeby wrócić do dawnych czasów odpowiedzi bez ingerencji w logikę programu.