kingdave2nd

Wer sich das Errorhandling im SQL 2005 anschaut, wird eine positive Überraschung entdecken: Der ambitionierte T-SQL Entwickler hat nun die Möglichkeit aehnlich wie in C# mit Try-Catch Funktionen zu arbeiten, um Fehler zu fangen. Natuerlich hat auch das so seine Tuecken, die es zu verstehen gilt.

Fangen wir mit einem einfache RAISERROR an, der innerhalb eines CATCH Blockes ausgefuehrt wird:

Prinzipiell also nicht allzu schwer. Innerhalb des TRY Blocks wird eine Änderung in einer Tabelle durchgeführt. Entsteht dabei kein Fehler, wird das COMMIT innerhlab des TRY Blocks ausgeführt. Im Fehlerfall wird direkt von der Fehlerstelle aus in den CATCH Block gesprungen. Mit XACT_STATE kann wird der Status meiner Transaktionen überprüft mit einem COMMIT oder ROLLBACK entsprechend regiert um den ersehnten @@TRANCOUNT Zustannd von "0" zu erreichen.

Anschliessend wird mit RASERROR noch ein Fehler ausgegeben und die Welt ist gut.

Entwickelt man nun eine Anwendung, deren Business Logik in der Datenbank gehalten werden soll, komm ich nun nicht drumherum ein sauberes Fehlerhandlichn zu implementieren. Dabei treten folgende Anforderungen auf:

1. Das ganze muss auch funkionieren, wenn Transaktion gestaffelt aufgerufen werden (Ich werde in diesem Artikel allerdings nicht auf DISTRIBUTED TRANSACTIONS eingehen).
2. Es müssen sowohl die SQL Server eigenen Fehler, als auch benutzerdefinierte Fehler ausgeben zu können.
3. Die Fehler müssen nachvollziehbar sein, sprich ein Fehlerprotokoll muss etabliert werden.
4. Der Code zur Steurung der Fehlerausgabe und protokollierung soll nur einmal implementiert werden.

Um dies nun zu erläutern, wird hier nun das folgende Prozedurmodell zu Grunde genommen:

P1 soll genau wie P2 im Fehlerfall die Prozedur pErrorHandling aufrufen. Allerdings sind diese prozeduren kaskadiert, wodurch ein Merhfacher Aufruf des ErrorHandler geschehen kann.

In P1 und P2 ist jeweils ein TRY...CATCH Block eingebaut.