Kompatybilność z wersjami PowerShell

Kompatybilność z wersjami PowerShell określa, które wydania tej powłoki obsługują moduły do zarządzania SQL Server.

Od Windows PowerShell 5.1 do PowerShell 7

Kompatybilność z wersjami PowerShell określa, czy dana wersja powłoki może załadować moduł SQL Server, odnaleźć jego zależności i poprawnie wykonać dostępne polecenia. W środowisku Windows występuje przede wszystkim Windows PowerShell 5.1, oparty na .NET Framework. Nowszy PowerShell 7 jest odrębną linią rozwojową, używającą platformy .NET i dostępną także poza systemem Windows. Sama obecność programu PowerShell na komputerze nie oznacza więc, że każdy moduł administracyjny będzie działał w każdej jego wersji.

Moduł SqlServer jest współczesnym modułem PowerShell przeznaczonym do pracy z SQL Server. Udostępnia między innymi polecenia Invoke-Sqlcmd, Backup-SqlDatabase, Restore-SqlDatabase, Get-SqlInstance i Get-SqlErrorLog. Starszy moduł SQLPS, dostarczany w ramach wcześniejszych wersji narzędzi SQL Server, ma znaczenie głównie dla zgodności ze starszymi skryptami. Nie należy automatycznie zastępować nazwy SQLPS nazwą SqlServer, ponieważ różnią się sposobem instalacji, wersjami zależności i zakresem zgodności.

Moduł SqlServer a środowisko uruchomieniowe

W praktyce trzeba rozróżnić wersję samego PowerShell od wersji modułu SqlServer. Polecenie $PSVersionTable pokazuje informacje o aktualnie uruchomionej powłoce, natomiast Get-Module -ListAvailable SqlServer pozwala sprawdzić, jakie wersje modułu są zainstalowane i gdzie znajdują się ich pliki. Dopiero porównanie tych danych z wymaganiami konkretnej wersji modułu umożliwia ocenę zgodności.

Wersje modułu instalowane z PowerShell Gallery mogą zawierać różne zależności, w tym biblioteki klienta SQL Server i składniki używane przez narzędzia SMO, czyli SQL Server Management Objects. Z tego powodu aktualizacja modułu może zmienić wymagania dotyczące wersji PowerShell albo platformy .NET. Instalowanie modułu bezpośrednio do środowiska produkcyjnego bez sprawdzenia wersji może doprowadzić do sytuacji, w której skrypt działa w jednej sesji, ale nie uruchamia się w innej.

Różnice między SQLPS i SqlServer

Starsze skrypty administracyjne często rozpoczynają pracę od załadowania modułu SQLPS albo korzystają z automatycznego importu zapewnianego przez starsze narzędzia SQL Server. Nowsze skrypty powinny jawnie używać modułu SqlServer, jeżeli jego polecenia i wersja są dostępne w danym środowisku. Sprawdzenie załadowanego modułu wykonuje się poleceniem Get-Module, a listę eksportowanych poleceń można uzyskać przez Get-Command -Module SqlServer.

Nie każda różnica objawia się komunikatem o braku modułu. Problemy mogą dotyczyć również niezaładowanej biblioteki .NET, konfliktu kilku wersji SMO, innej polityki wykonywania skryptów albo uruchomienia powłoki 32-bitowej zamiast 64-bitowej. Znaczenie ma także sposób instalacji: moduł zainstalowany dla bieżącego użytkownika może być niewidoczny dla innego konta, usługi lub zadania Harmonogramu zadań. Dlatego diagnostyka powinna obejmować ścieżkę modułów zwracaną przez $env:PSModulePath, wersję polecenia oraz konto, w ramach którego działa skrypt.

Sprawdzanie zgodności przed uruchomieniem skryptu

Bezpieczna weryfikacja zaczyna się od ustalenia wersji PowerShell, systemu operacyjnego, platformy .NET oraz modułu SqlServer. Przydatne są polecenia $PSVersionTable, Get-InstalledModule SqlServer i Get-Module -ListAvailable SqlServer. Warto również sprawdzić, czy polecenie Invoke-Sqlcmd jest dostępne oraz czy testowe połączenie wykorzystuje właściwą nazwę instancji, metodę uwierzytelniania i parametry szyfrowania.

Jeżeli moduł wymaga składników dostępnych wyłącznie w Windows PowerShell, PowerShell 7 w systemie Windows może użyć mechanizmu zgodności z Windows PowerShell, uruchamianego parametrem -UseWindowsPowerShell przy imporcie modułu. Nie jest to jednak uniwersalne rozwiązanie dla modułów zależnych od pełnego środowiska Windows PowerShell, a sesja zgodności ma ograniczenia dotyczące typów .NET i komunikacji między procesami. Przy błędzie należy ustalić, czy problem wynika z wersji powłoki, wersji modułu, zależności SMO, uprawnień czy samego połączenia z SQL Server.