Język a komunikaty błędów

Zależność języka od komunikatów błędów określa, w jakiej wersji językowej SQL Server zwraca opisy napotkanych problemów.

Jak SQL Server wybiera język komunikatu błędu

SQL Server może zwracać komunikaty diagnostyczne w różnych wersjach językowych. Wybór języka zależy przede wszystkim od ustawień sesji, z której wykonano instrukcję. Informację o bieżącym języku można odczytać za pomocą funkcji @@LANGUAGE. Ustawienie to jest przypisane do połączenia z serwerem, dlatego dwie sesje korzystające z tej samej instancji mogą otrzymać opis tego samego błędu w różnych językach.

Język sesji można zmienić instrukcją SET LANGUAGE, podając nazwę języka obsługiwaną przez daną instancję, na przykład SET LANGUAGE Polish; albo SET LANGUAGE us_english;. Polecenie wpływa nie tylko na teksty komunikatów, lecz także na elementy zależne od języka, w tym nazwy dni i miesięcy oraz domyślny format daty. Z tego powodu zmiana języka nie powinna być traktowana wyłącznie jako ustawienie wyglądu błędów.

Język komunikatu a numer i treść błędu

Zmiana języka nie zmienia samego zdarzenia, które wystąpiło w silniku. Numer błędu, poziom ważności, stan oraz procedura lub instrukcja zgłaszająca problem pozostają odrębnymi informacjami diagnostycznymi. Przykładowo naruszenie ograniczenia klucza podstawowego nadal będzie identyfikowane tym samym mechanizmem, niezależnie od tego, czy opis zostanie zwrócony po polsku, czy po angielsku. W praktyce numer błędu jest stabilniejszym identyfikatorem niż przetłumaczony tekst.

Teksty komunikatów systemowych są przechowywane w katalogu komunikatów SQL Server i są powiązane z identyfikatorem języka. Widoki katalogowe, takie jak sys.messages, zawierają między innymi numer komunikatu, język, poziom ważności oraz tekst. Do sprawdzenia dostępnych języków i ich właściwości można użyć procedury sp_helplanguage. Jeżeli dla określonego komunikatu nie ma wersji w żądanym języku, SQL Server może użyć wersji języka zastępczego, zależnie od dostępnych zasobów i konfiguracji instalacji.

Wpływ ustawień sesji na analizę błędów

Podczas diagnostyki trzeba odróżnić język ustawiony w SQL Server od języka narzędzia klienckiego, systemu operacyjnego i aplikacji. Management Studio, aplikacja korzystająca z dostawcy sterownika oraz skrypt uruchomiony z wiersza poleceń mogą otwierać sesje z innymi ustawieniami początkowymi. Sam interfejs programu może być po polsku, podczas gdy serwer zwróci komunikat po angielsku, ponieważ język sesji został ustalony niezależnie od języka menu aplikacji.

Znaczenie ma także sposób nawiązywania połączenia. Ustawienia domyślnego języka mogą być przypisane do loginu, a ustawienia sesji mogą zostać później zmienione przez sterownik, aplikację lub polecenie SET LANGUAGE. W razie rozbieżności warto zapisać wynik SELECT @@LANGUAGE;, a następnie sprawdzić ustawienia daty funkcją @@DATEFORMAT. Jest to istotne, ponieważ komunikat o błędzie konwersji daty może wskazywać rzeczywisty problem z interpretacją danych według formatu sesji, a nie tylko różnicę tłumaczenia.

Własne komunikaty dodawane procedurą sp_addmessage również mogą mieć wersje językowe. Dla jednego numeru komunikatu można zdefiniować teksty w różnych językach, a następnie wywołać komunikat przez RAISERROR. Instrukcja THROW może zgłaszać błąd z numerem, stanem i tekstem podanym bezpośrednio w kodzie albo ponownie przekazywać przechwycony wyjątek. Przy analizie aplikacji należy więc ustalić, czy tekst pochodzi z katalogu systemowego, własnego komunikatu, czy z warstwy programu, która tłumaczy błąd po otrzymaniu odpowiedzi serwera.

Praktyczne porównywanie komunikatów w SQL Server

Najbezpieczniejsza analiza błędu polega na zapisaniu pełnego komunikatu razem z numerem, poziomem ważności, stanem, nazwą bazy, nazwą obiektu i instrukcją, która go wywołała. Samo tłumaczenie może różnić się składnią, długością lub terminologią, ale numer błędu pozwala porównać zdarzenia między środowiskami. W logach aplikacji warto zachowywać zarówno oryginalny tekst, jak i dane strukturalne zwracane przez sterownik SQL Server.

Jeżeli ten sam skrypt daje różne opisy w dwóch narzędziach, należy porównać język sesji, domyślny język loginu, wersję i edycję instancji oraz dostępność odpowiednich zasobów językowych. Pomocne jest także celowe wykonanie testu z jednoznacznie ustawionym językiem, na przykład po użyciu SET LANGUAGE us_english;. Nie należy jednak opierać logiki programu na porównywaniu całych zdań komunikatów, ponieważ tekst może zależeć od języka, wersji SQL Server i parametrów konkretnego błędu. Interpretacja komunikatów SQL Server wymaga zachowania rozdziału między ustawieniami sesji, silnikiem bazy danych i kodem aplikacji.

W środowisku, w którym błędy są przekazywane do systemu monitoringu, przydatne jest normalizowanie komunikatów według numeru i stanu zamiast według ich dosłownego brzmienia. Dzięki temu ten sam problem nie zostanie potraktowany jako dwa różne zdarzenia tylko dlatego, że jedna sesja działa po polsku, a druga po angielsku. Tekst komunikatu nadal pozostaje potrzebny operatorowi, lecz jako opis pomocniczy, a nie jedyny klucz klasyfikacji.