Domyślny język serwera

Domyślny język serwera to ustawienie regionalne automatycznie stosowane dla nowych loginów na instancji SQL Server.

Rola ustawienia „Domyślny język serwera” w SQL Server

„Domyślny język serwera” w Microsoft SQL Server jest opcją konfiguracyjną instancji, która określa język przypisywany automatycznie nowym loginom, jeżeli podczas ich tworzenia nie wskazano innego języka. Ustawienie dotyczy loginów serwera, czyli podmiotów uwierzytelnianych na poziomie instancji SQL Server. Nie jest to ustawienie języka interfejsu systemu Windows, języka Management Studio ani języka konkretnej bazy danych.

Język przypisany do loginu wpływa na początkowe ustawienia sesji po zalogowaniu. Obejmuje między innymi nazwy miesięcy i dni tygodnia, sposób interpretowania niektórych wartości daty oraz domyślny format daty. W praktyce może to zmienić rezultat zapytań używających funkcji zależnych od języka, takich jak DATENAME, a także zachowanie poleceń, w których format daty nie został określony jednoznacznie.

Powiązanie języka z loginem i sesją

Podczas uwierzytelniania SQL Server ustala właściwości nowej sesji na podstawie konfiguracji loginu. Jeżeli login ma zapisany własny język domyślny, jest on używany w pierwszej kolejności. Jeżeli język nie został określony dla tworzonego loginu, SQL Server wykorzystuje wartość ustawienia „default language” instancji. Zmiana domyślnego języka serwera nie nadpisuje automatycznie języka już istniejących loginów.

Język sesji można tymczasowo zmienić poleceniem SET LANGUAGE. Taka zmiana obowiązuje tylko w bieżącej sesji i nie modyfikuje konfiguracji instancji ani właściwości loginu. Należy odróżnić ją od polecenia ALTER LOGIN, które zapisuje język przypisany konkretnemu loginowi i będzie miało zastosowanie przy kolejnych logowaniach. Po zmianie języka sesji zmienia się także powiązany z nim format daty, dlatego zapytania aplikacyjne powinny unikać niejednoznacznych zapisów tekstowych dat.

Ustawienie nie tłumaczy nazw tabel, kolumn, procedur, komunikatów aplikacji ani danych przechowywanych w bazie. Nie zmienia również kodowania tekstu. Dotyczy przede wszystkim ustawień językowych środowiska wykonania zapytań oraz wartości pochodnych, takich jak format daty i nazwy elementów kalendarza zwracane przez funkcje SQL Server.

Sprawdzanie wartości i wpływu na nowe loginy

Aktualną wartość konfiguracji instancji można sprawdzić za pomocą procedury sp_configure, po wcześniejszym włączeniu wyświetlania opcji zaawansowanych, jeżeli jest to wymagane przez wersję i konfigurację serwera. Przykładowy odczyt konfiguracji ma postać EXEC sp_configure 'default language';. Wynik zawiera wartość konfiguracyjną odpowiadającą identyfikatorowi języka z katalogu języków SQL Server.

Lista języków dostępnych w danej instancji jest udostępniana przez widok zgodności sys.syslanguages. Zawiera on między innymi identyfikator języka, nazwę, skróty nazw miesięcy i dni oraz ustawienie dateformat. W nowszych rozwiązaniach administracyjnych warto również sprawdzić właściwości loginów w widokach katalogowych, takich jak sys.server_principals, aby potwierdzić, jaki język domyślny zapisano dla konkretnego konta.

Przy tworzeniu loginu można jawnie określić język za pomocą składni CREATE LOGIN ... WITH DEFAULT_LANGUAGE = nazwa_języka. Dla istniejącego loginu stosuje się ALTER LOGIN ... WITH DEFAULT_LANGUAGE = nazwa_języka. Jawne wskazanie języka jest czytelniejsze niż poleganie wyłącznie na ustawieniu instancji, szczególnie gdy wiele aplikacji korzysta z jednej instancji i wymagają one przewidywalnego formatu sesji.

Skutki diagnostyczne niejednoznacznego języka

Różnice w języku loginu często ujawniają się przy analizie błędów związanych z datami. Ten sam tekst reprezentujący datę może zostać zinterpretowany odmiennie w sesji używającej formatu mdy oraz w sesji używającej formatu dmy. Dlatego diagnostyka powinna obejmować sprawdzenie języka i formatu bieżącej sesji, na przykład przez SELECT @@LANGUAGE, @@DATEFIRST, DATEFORMAT, przy czym informację o formacie daty można odczytać także z właściwości języka w sys.syslanguages.

Bezpieczniejszym rozwiązaniem jest używanie typów parametrów daty i czasu w zapytaniach aplikacji zamiast przekazywania dat jako niejednoznacznych ciągów znaków. W kodzie T-SQL należy również zachować ostrożność przy funkcjach konwertujących tekst na datę i jawnie określać styl konwersji tam, gdzie dane wejściowe mogą mieć różny zapis. Samo ustawienie domyślnego języka serwera nie naprawia błędnych danych zapisanych wcześniej ani nie gwarantuje zgodności aplikacji, która zakłada konkretny format daty.

W przypadku problemu należy porównać konfigurację instancji, właściwości danego loginu oraz polecenia wykonywane przez aplikację po nawiązaniu połączenia. Trzeba też uwzględnić możliwość, że biblioteka kliencka lub kod aplikacji wykonuje SET LANGUAGE albo inne polecenia inicjalizujące sesję. Taki sposób analizy pozwala odróżnić wpływ ustawienia „Domyślny język serwera” od zmian wykonywanych już po zalogowaniu.