Wersje językowe SQL Server

Wersje językowe SQL Server dotyczą lokalizacji komunikatów i narzędzi, nie samej struktury silnika bazodanowego.

Co oznaczają wersje językowe SQL Server

Wersja językowa SQL Server opisuje przede wszystkim sposób prezentowania komunikatów, nazw elementów interfejsu oraz dokumentacji i narzędzi administracyjnych. Lokalizacja nie zmienia podstawowej gramatyki języka T-SQL, modelu relacyjnego ani struktury silnika bazodanowego. Instrukcje takie jak SELECT, INSERT, UPDATE, DELETE i CREATE TABLE pozostają zapisane w języku SQL niezależnie od języka instalacji.

Trzeba rozdzielić język produktu od sortowania i porównywania tekstu. Za te drugie funkcje odpowiada collation, czyli zestaw reguł określających między innymi kolejność znaków, rozróżnianie wielkości liter oraz sposób traktowania znaków diakrytycznych. Zmiana języka komunikatów nie powoduje automatycznej zmiany kolacji bazy danych ani kolumn tekstowych. Odwrotna zależność również nie zachodzi: wybór polskiej kolacji nie oznacza, że interfejs SQL Server będzie spolszczony.

Język komunikatów, narzędzi i instalatora

Podczas instalacji SQL Server wybierany jest język używany przez składniki instalacyjne i komunikaty dostępne dla danej dystrybucji. Zależnie od wydania oraz użytych nośników instalacyjnych mogą być dostępne dodatkowe pakiety językowe. Ich zadaniem jest dostarczenie przetłumaczonych zasobów, a nie utworzenie odrębnego silnika bazodanowego. Ta sama instancja może wykonywać te same operacje niezależnie od tego, czy administrator korzysta z angielskiej, polskiej czy innej lokalizacji narzędzia.

Komunikaty błędów silnika są powiązane z identyfikatorem komunikatu oraz językiem. W katalogu systemowym przechowywane są wersje tekstów przeznaczone dla obsługiwanych języków, dzięki czemu ten sam błąd może zostać pokazany w różnych językach bez zmiany przyczyny problemu. Dotyczy to między innymi błędów składni, problemów z uprawnieniami, blokad, połączeniami oraz operacjami na obiektach. Sam identyfikator błędu i kontekst wykonania pozostają ważniejsze diagnostycznie niż tłumaczenie jego opisu.

Osobną kwestią są narzędzia klienckie, takie jak SQL Server Management Studio, instalowane niezależnie od samego silnika. Ich język interfejsu może wynikać z osobnego pakietu lub ustawień środowiska. Dlatego serwer może zwracać komunikaty w jednym języku, a narzędzie administracyjne prezentować własne elementy menu w innym. Przy analizie zgłoszenia należy ustalić, czy problem dotyczy serwera, instalatora, narzędzia klienckiego, czy jedynie tłumaczenia komunikatu.

Ustawienia językowe sesji T-SQL

SQL Server obsługuje również język sesji. Instrukcja SET LANGUAGE ustawia język używany w bieżącym połączeniu i wpływa między innymi na nazwy miesięcy oraz dni tygodnia rozpoznawane przez funkcje i konwersje dat. Stan można sprawdzić za pomocą zmiennej @@LANGUAGE. Ustawienie sesji nie jest tym samym co język instalacji, ponieważ może zostać zastosowane dla konkretnego połączenia aplikacji, bez modyfikowania pozostałych użytkowników.

Język sesji wiąże się także z domyślnym formatem daty. Polecenie SET DATEFORMAT określa kolejność składników daty, na przykład dzień, miesiąc i rok, natomiast SET LANGUAGE może ustawić powiązane zachowanie domyślne. Niebezpieczne jest przekazywanie niejednoznacznych literałów tekstowych, takich jak zapis zawierający wyłącznie cyfry bez jednoznacznego formatu. Bezpieczniejszym rozwiązaniem jest przekazywanie wartości daty jako parametrów zapytania albo stosowanie jednoznacznego formatu obsługiwanego przez SQL Server.

Domyślny język może być przypisany do loginu. W konfiguracji loginu SQL Server można wskazać język domyślny, a nowe sesje tego użytkownika otrzymają odpowiednie ustawienie, o ile aplikacja nie zmieni go później własnym poleceniem. Nie należy jednak zakładać, że ustawienie loginu zmienia język komunikatów instalacji lub interfejsu Management Studio. Są to niezależne warstwy konfiguracji i wymagają osobnego sprawdzenia.

Rozróżnianie lokalizacji od kolacji i formatów danych

W praktyce najwięcej pomyłek wynika z utożsamiania wersji językowej z kolacją. Kolacja może wpływać na porównania tekstów, sortowanie, indeksy oraz sposób interpretacji znaków, ale nie tłumaczy nazw poleceń T-SQL i nie lokalizuje całego interfejsu. Przy problemach z polskimi znakami, kolejnością sortowania albo wynikami porównań należy analizować kolację serwera, bazy danych, kolumny i wyrażenia, a nie tylko ustawienie języka komunikatów.

Ważne jest również odróżnienie lokalizacji od ustawień regionalnych systemu operacyjnego i aplikacji. Program kliencki może formatować daty, liczby lub waluty po swojej stronie, zanim wyśle wartości do SQL Server. Z kolei serwer może interpretować tekstową datę zgodnie z językiem i formatem sesji. Taka różnica potrafi powodować błędne daty, nieoczekiwane wyniki konwersji albo awarie występujące tylko dla jednego użytkownika. Diagnostyka powinna obejmować wersję silnika, język sesji, wartość @@LANGUAGE, ustawienie formatu daty, kolację oraz sposób parametryzowania zapytań.

W środowisku administracyjnym przydatne jest także porównanie komunikatu w oryginalnym języku z jego tłumaczeniem oraz zapisanie numeru błędu, nazwy procedury i fragmentu zapytania. Tłumaczenie może zmieniać stylistykę opisu, lecz nie powinno być traktowane jako dowód innej klasy problemu. Dla powtarzalnych wdrożeń warto dokumentować wymagany język narzędzi, domyślny język loginów i oczekiwaną kolację, ponieważ każdy z tych parametrów odpowiada za inny obszar działania SQL Server.