Funkcja ERROR_PROCEDURE()

Funkcja ERROR_PROCEDURE() zwraca nazwę procedury, w której wystąpił błąd.

Skąd przyszedł błąd, a nie tylko co się stało

ERROR_PROCEDURE w Microsoft SQL Server zwraca nazwę procedury składowanej albo wyzwalacza, w którym powstał przechwycony błąd. Jeśli błąd wystąpił w kodzie wykonanym bezpośrednio, poza jakąkolwiek procedurą, funkcja zwróci wartość pustą i nie jest to usterka, tylko poprawne zachowanie. W połączeniu z numerem wiersza daje to najbardziej praktyczną informację diagnostyczną: wiadomo nie tylko jaki był błąd, ale w którym miejscu kodu go szukać.

Dziennik zdarzeń, który faktycznie skraca szukanie

Wartość tej funkcji nabiera znaczenia w rozbudowanych rozwiązaniach, gdzie jedna procedura woła drugą, ta trzecią, a całość uruchamia zaplanowane zadanie nocne. Bez nazwy procedury komunikat o naruszeniu ograniczenia mówi niewiele. Praktyką jest zapisywanie do własnej tabeli dziennika kompletu danych: nazwy procedury, numeru wiersza, numeru i treści błędu, nazwy użytkownika oraz czasu. Alternatywą, stosowaną gdy nie chce się tworzyć własnej tabeli, jest przekazanie tych informacji dalej w ponownie zgłaszanym błędzie, tak aby dotarły do aplikacji wywołującej. Każde z podejść ma koszt: własna tabela wymaga utrzymania i czyszczenia, przekazywanie w komunikacie łatwo gubi się w warstwie aplikacji.

Wyzwalacze, kod dynamiczny i mylące nazwy

Warto pamiętać, że funkcja poda nazwę miejsca, w którym błąd powstał, a nie tego, które go przechwyciło. Jeśli procedura zewnętrzna obsługuje błąd rzucony przez wewnętrzną, zobaczymy nazwę wewnętrznej. Przy zapytaniach budowanych dynamicznie i wykonywanych jako tekst nazwa bywa pusta albo wskazuje procedurę, która ten tekst uruchomiła, co przy diagnozie potrafi mylić. Osobny przypadek to wyzwalacze: nazwa wyzwalacza w dzienniku bywa zaskoczeniem dla osoby przekonanej, że wykonuje zwykłą operację zapisu. Nie należy też opierać logiki aplikacji na porównywaniu nazw procedur, bo każda zmiana nazwy cicho psuje taką zależność.

Gdy nocne zadania przestają dochodzić do końca

Część awarii wyglądających na błędy bazy ma źródło poza bazą: zerwane połączenie sieciowe, wyłączający się w nocy komputer, zapełniony dysk albo uszkodzony kontroler dysku. Warszawskie Pogotowie Komputerowe sprawdza właśnie tę warstwę u klientów firmowych, którzy trzymają bazę na stacji roboczej lub niewielkim serwerze. Prowadzimy diagnostykę nośników, porządkujemy przestrzeń dyskową i konfigurację zasilania, a na czas naprawy udostępniamy laptop zastępczy, żeby praca nie stanęła.