Kompatybilność funkcji T-SQL określa, od której wersji SQL Server dana konstrukcja języka jest obsługiwana.
Wersja aparatu SQL Server a dostępność funkcji T-SQL
Kompatybilność funkcji T-SQL zależy przede wszystkim od wersji aparatu SQL Server, na którym wykonywane jest zapytanie. Baza danych utworzona w starszej wersji może zostać przeniesiona do nowszego SQL Server, ale nie oznacza to, że każda funkcja będzie dostępna po stronie starszej instancji. Przykładowo CONCAT oraz funkcje takie jak EOMONTH i DATEFROMPARTS pojawiły się w SQL Server 2012, natomiast STRING_SPLIT i obsługa funkcji JSON zostały wprowadzone w SQL Server 2016.
W SQL Server 2017 dodano między innymi agregującą funkcję tekstową STRING_AGG oraz funkcję TRIM. SQL Server 2022 wprowadził między innymi DATETRUNC i GENERATE_SERIES. Jeżeli kod korzysta z funkcji niedostępnej w uruchomionej wersji silnika, parser lub wykonawca zapytania zwróci błąd, nawet gdy sama składnia wygląda poprawnie. Z tego powodu przy analizie skryptu trzeba ustalić dokładną wersję SQL Server, a nie tylko nazwę produktu.
Poziom zgodności bazy danych i jego ograniczenia
SQL Server rozróżnia wersję silnika od poziomu zgodności bazy danych, określanego wartością compatibility level. Poziom można sprawdzić zapytaniem SELECT name, compatibility_level FROM sys.databases;, a wersję instancji między innymi przez SELECT SERVERPROPERTY('ProductVersion'), SERVERPROPERTY('ProductLevel'), SERVERPROPERTY('Edition');. Poziom zgodności wpływa na sposób interpretowania części składni, optymalizację zapytań oraz dostępność niektórych mechanizmów języka, ale nie jest zamiennikiem aktualizacji aparatu SQL Server.
Przykładowo STRING_SPLIT wymaga co najmniej poziomu zgodności 130, czyli poziomu kojarzonego z SQL Server 2016. Przy niższym poziomie zgodności wywołanie może zakończyć się błędem, mimo że baza działa na nowszej instancji. Podobna zależność dotyczy OPENJSON, które również wymaga poziomu 130 lub wyższego. Dla funkcji STRING_AGG sama funkcja jest dostępna od SQL Server 2017, natomiast składnia porządkowania elementów w klauzuli WITHIN GROUP wymaga poziomu zgodności co najmniej 140.
Podniesienie compatibility level nie dodaje funkcji do starszej wersji serwera. Nie można uruchomić funkcji dostępnej dopiero w SQL Server 2022 na instancji SQL Server 2016 przez zmianę ustawienia bazy. Zmiana poziomu zgodności może również zmienić plan wykonania zapytań, dlatego przed jej zastosowaniem należy sprawdzić skrypty, procedury, widoki, funkcje użytkownika i testy aplikacji.
Przykłady różnic między generacjami funkcji
W SQL Server 2012 funkcja CONCAT umożliwiła łączenie wartości z niejawną konwersją do typu tekstowego i traktowaniem wartości NULL jako pustego ciągu. W tej samej wersji pojawiły się funkcje tworzące wartości daty z osobnych składników, między innymi DATEFROMPARTS, oraz funkcja EOMONTH zwracająca ostatni dzień miesiąca. W starszych wersjach podobne operacje wymagały innych wyrażeń, jawnych konwersji albo własnych funkcji pomocniczych.
SQL Server 2016 dodał STRING_SPLIT do rozdzielania ciągu według pojedynczego separatora. Funkcja zwraca tabelę wartości, ale w starszej wersji SQL Server nie jest rozpoznawana. W tej samej generacji pojawiły się JSON_VALUE, JSON_QUERY i OPENJSON, służące odpowiednio do odczytu wartości skalarnej, fragmentu obiektu lub tablicy oraz rozbijania dokumentu JSON na wiersze. Funkcje te dotyczą mechanizmu JSON w SQL Server i nie należy utożsamiać ich z rozwiązaniami implementowanymi w innych silnikach baz danych.
W SQL Server 2017 funkcja STRING_AGG pozwala połączyć wartości z wielu wierszy w jeden ciąg, używając wskazanego separatora. SQL Server 2022 udostępnia natomiast DATETRUNC, która obcina część daty do wskazanej precyzji, na przykład do miesiąca lub dnia, oraz GENERATE_SERIES, która zwraca tabelę kolejnych wartości liczbowych albo dziesiętnych. Nowe warianty funkcji powinny być używane dopiero po potwierdzeniu wersji instancji i poziomu zgodności konkretnej bazy.
Weryfikacja zgodności przed wdrożeniem skryptu
Przy przenoszeniu procedury lub zapytania należy najpierw ustalić minimalną wersję SQL Server wymaganą przez wszystkie użyte funkcje. Warto przejrzeć także funkcje zagnieżdżone, wyrażenia w widokach, definicje kolumn obliczanych i skrypty migracyjne, ponieważ pojedyncze użycie STRING_SPLIT, OPENJSON albo DATETRUNC może uniemożliwić kompilację całego obiektu. Sam fakt, że kod został poprawnie zapisany w narzędziu edycyjnym, nie potwierdza jego zgodności z docelową instancją.
Praktyczna kontrola obejmuje wykonanie skryptu na kopii bazy lub środowisku testowym, sprawdzenie poziomu zgodności oraz analizę komunikatów parsera. Należy rozdzielić błąd braku funkcji od błędu poziomu zgodności i od błędu typu danych. Na przykład działanie STRING_SPLIT może wymagać poziomu 130, ale nieprawidłowy typ argumentu, separator o nieodpowiedniej długości albo założenie o kolejności zwracanych wierszy stanowią osobne problemy logiczne.
W środowisku serwerowym zgodność powinno się potwierdzać dla każdej instancji, na której kod ma działać, z uwzględnieniem edycji, wersji aktualizacji i ustawień konkretnej bazy. Po zmianie wersji SQL Server lub compatibility level trzeba ponownie uruchomić testy procedur, raportów i zadań cyklicznych oraz sprawdzić plany wykonania zapytań. Takie postępowanie ogranicza ryzyko, że funkcja z nowszego T-SQL zostanie wdrożona do starszej instancji albo będzie działała inaczej po zmianie poziomu zgodności.
