Funkcja ERROR_MESSAGE()

Funkcja ERROR_MESSAGE() zwraca pełną treść komunikatu ostatnio wystąpionego błędu.

Miejsce funkcji w obsłudze wyjątków T-SQL

ERROR_MESSAGE() należy do rodziny funkcji systemowych Transact-SQL dostępnych wewnątrz bloku BEGIN CATCH. Zwraca pełny tekst komunikatu ostatniego błędu przechwyconego w bieżącym zakresie, już po podstawieniu parametrów — jeśli komunikat systemowy zawiera nazwę tabeli albo wartość naruszającą ograniczenie, znajdą się one w zwróconym łańcuchu. Towarzyszą jej ERROR_NUMBER() z numerem błędu, ERROR_SEVERITY() ze stopniem ważności, ERROR_STATE() ze stanem, ERROR_LINE() z numerem wiersza oraz ERROR_PROCEDURE() z nazwą procedury, w której doszło do awarii. Komplet tych wartości zapisany do tabeli dziennika daje pełny obraz zdarzenia.

Zachowanie w praktyce i różnice względem THROW

Poza blokiem CATCH funkcja zwraca NULL — to najczęstsze źródło nieporozumień, bo zapytanie testowe uruchomione samodzielnie nie pokazuje niczego. Wartość pozostaje dostępna, dopóki nie zostanie przechwycony kolejny błąd, więc wywołanie jej po zagnieżdżonej konstrukcji TRY CATCH zwróci komunikat z wnętrza, nie z zewnątrz. Przy przekazywaniu błędu dalej klasyczne podejście używało RAISERROR z tekstem pobranym z tej funkcji, ale wymuszało to ręczne podanie stopnia ważności i gubiło oryginalny numer. Instrukcja THROW bez argumentów, dostępna w nowszych wersjach silnika, przekazuje wyjątek w oryginalnej postaci wraz z numerem i stanem, dlatego jest dziś preferowana tam, gdzie liczy się wierne zgłoszenie problemu do warstwy aplikacji.

Czego funkcja nie przechwyci

Blok TRY nie reaguje na błędy kompilacji ani na błędy rozpoznawania nazw powstające przy odroczonym wiązaniu, więc literówka w nazwie tabeli w tej samej partii kodu wywali skrypt, zanim CATCH w ogóle zaistnieje. Nie przechwyci też przerwania sesji, przekroczenia limitu czasu po stronie klienta ani błędów o stopniu ważności 20 i wyższym, które zamykają połączenie. Osobna pułapka to zapominanie o stanie transakcji: po niektórych błędach transakcja przechodzi w stan niezdatny do zatwierdzenia i przed próbą zapisu komunikatu do dziennika trzeba sprawdzić XACT_STATE(), inaczej samo logowanie zakończy się kolejnym wyjątkiem.

Diagnostyka baz systemów handlowych

W codziennej pracy z Subiektem, WAPRO i Comarch komunikaty przechwycone tą funkcją są zwykle pierwszym twardym śladem przy awarii — pokazują, czy problem to naruszenie klucza obcego przy imporcie dokumentów, przepełnienie kolumny numerycznej, czy zakleszczenie dwóch sesji przy wystawianiu faktur. Wdrażamy i serwisujemy takie środowiska oparte o SQL Server, analizujemy dzienniki błędów, prowadzimy naprawy po nieudanych aktualizacjach i odtwarzamy bazy z kopii, gdy uszkodzeniu uległ plik danych. Pracujemy przez całą dobę, siedem dni w tygodniu, co przy bazie blokującej sprzedaż ma znaczenie zasadnicze.