Zmienne PowerShell mogą być przekazywane do skryptów T-SQL uruchamianych z poziomu tego środowiska.
Jak PowerShell przekazuje wartości do T-SQL
PowerShell i T-SQL są wykonywane przez różne środowiska, dlatego zmienna utworzona w PowerShell nie staje się automatycznie zmienną dostępną wewnątrz SQL Server. Przykładowo zapis $nazwaBazy = "Magazyn" tworzy zmienną po stronie PowerShell, natomiast w T-SQL zmienna lokalna ma postać DECLARE @nazwaBazy sysname;. Aby przekazać wartość między tymi środowiskami, potrzebny jest mechanizm klienta uruchamiającego zapytanie, taki jak polecenie Invoke-Sqlcmd z modułu SqlServer, albo jawne parametryzowanie zapytania przez obiekt połączenia ADO.NET.
W praktyce występują dwa różne sposoby podstawiania wartości. Pierwszy korzysta ze zmiennych SQLCMD. PowerShell przekazuje pary w rodzaju Tryb=Test, a skrypt T-SQL odwołuje się do nich składnią $(Tryb). Drugi sposób polega na użyciu parametrów polecenia SQL, na przykład @IdKlienta, do których wartość jest przypisywana przez obiekt SqlParameter. Te mechanizmy nie są równoważne: $(Tryb) jest podstawieniem tekstowym wykonywanym przed analizą instrukcji przez SQL Server, a parametr SQL jest wartością przekazywaną osobno do przygotowanego zapytania.
Zmienne SQLCMD w poleceniu Invoke-Sqlcmd
Jeżeli skrypt jest uruchamiany przez Invoke-Sqlcmd, można przekazać wartości z PowerShell za pomocą parametru -Variable. Przykładowy skrypt może wyglądać następująco: SELECT N'Środowisko: $(Srodowisko)' AS Opis;. W PowerShell wartość można przygotować poleceniem $srodowisko = "Test", a następnie uruchomić skrypt przez Invoke-Sqlcmd -ServerInstance "localhost" -Database "Magazyn" -InputFile ".\raport.sql" -Variable "Srodowisko=$srodowisko". W tym przypadku SQLCMD zastępuje odwołanie $(Srodowisko) przekazanym tekstem.
Wartość podstawiana przez SQLCMD musi tworzyć poprawny fragment tekstu T-SQL. Jeśli ma być użyta jako tekst, skrypt powinien uwzględniać apostrofy, na przykład SELECT N'$(Srodowisko)';. Samo podstawienie nie dodaje automatycznie bezpiecznego cytowania ani nie konwertuje tekstu do typu liczbowego. Wartość liczbowa może zostać użyta w wyrażeniu takim jak WHERE Id = $(Id), ale tylko wtedy, gdy przed uruchomieniem zostanie sprawdzona jako liczba. Nazwa tabeli, kolumny lub sortowania nie może być traktowana jak zwykły parametr wartościowy; przy dynamicznych identyfikatorach wymagane są jawne reguły walidacji i odpowiednie mechanizmy T-SQL, takie jak QUOTENAME.
Parametry zapytań a podstawianie tekstu
Do przekazywania danych użytkownika, ścieżek, identyfikatorów i innych wartości zwykle właściwsze są parametry SQL niż bezpośrednie wstawianie tekstu do polecenia. PowerShell może utworzyć obiekt System.Data.SqlClient.SqlConnection lub odpowiednią klasę klienta, zbudować SqlCommand, a następnie dodać parametr przez $command.Parameters.Add("@Id", [System.Data.SqlDbType]::Int) i ustawić jego właściwość Value. Wykonywane zapytanie zawiera wtedy WHERE Id = @Id, a nie wartość sklejona w ciąg znaków. SQL Server otrzymuje strukturę polecenia i dane oddzielnie, dzięki czemu apostrofy oraz inne znaki występujące w tekście nie zmieniają składni zapytania.
Przy Invoke-Sqlcmd można również użyć skryptu T-SQL przyjmującego parametry procedury składowanej. Przykładowo procedura może definiować @IdKlienta int, a PowerShell wywołuje ją przez polecenie z parametrem po stronie klienta albo przez przygotowany skrypt. Trzeba jednak rozróżniać zmienną PowerShell, zmienną SQLCMD i parametr procedury: zapis $IdKlienta jest interpretowany przez PowerShell, zapis $(IdKlienta) jest charakterystyczny dla podstawiania SQLCMD, a zapis @IdKlienta należy do składni T-SQL. Pomylenie tych oznaczeń często prowadzi do błędów składni, pustych wartości albo wykonania zapytania z nieoczekiwanym tekstem.
Diagnostyka skryptów i komputerów uruchamiających T-SQL
Problemy z przekazywaniem zmiennych warto diagnozować na kilku poziomach. Najpierw należy sprawdzić, czy moduł SqlServer jest dostępny poleceniem Get-Command Invoke-Sqlcmd oraz czy używany użytkownik ma uprawnienia do wskazanej instancji SQL Server i bazy. Następnie trzeba porównać dokładną nazwę zmiennej w parametrze -Variable z nazwą używaną w skrypcie. SQLCMD rozróżnia nazwę zmiennej jako tekstowy identyfikator, a brak przekazanej wartości może skutkować pozostawieniem nierozwiniętego wyrażenia $(Nazwa) i błędem parsowania.
Ważne są także typy danych, kodowanie oraz sposób obsługi błędów. Wartość odczytana z pliku lub argumentu PowerShell jest tekstem, nawet jeśli zawiera cyfry; przed użyciem jako liczby powinna zostać jawnie zweryfikowana i przekonwertowana. Połączenie powinno wskazywać właściwą instancję SQL Server, bazę oraz tryb uwierzytelniania, a skrypt PowerShell powinien reagować na błędy wykonania zamiast traktować nieudane polecenie jak sukces. Przy diagnostyce laptopa lub komputera PC sprawdza się między innymi wersję PowerShell, obecność modułu SqlServer, konfigurację klienta SQL Server, dostępność sieciową instancji oraz treść skryptu przekazywanego do Invoke-Sqlcmd. Dzięki temu można oddzielić błąd samego T-SQL od problemu środowiska uruchomieniowego.
