Du willst auch bloggen? -  Dann hol dir hier einen Weblog kostenlos von tell-it.net

SQL Server 2005 und Errorhandling

geschrieben von kingdave2nd | 4 Mär, 2006

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:

IF

OBJECT_ID ( 'P1', 'P' ) IS NOT NULL DROP PROCEDURE P1;GO

CREATE

PROCEDURE P1
@test nvarchar(255)

AS

BEGIN TRY BEGIN TRANSACTION test1
--Writing some stuff to database INSERT INTO tbltest (charvalue) VALUES (@test) COMMIT TRANSACTION test1END TRY
BEGIN CATCH --Rolling back uncommittable statements IF (XACT_STATE()) = -1 ROLLBACK TRANSACTION test1 --For writing to EventLog, we have to commit all commitable statements IF (XACT_STATE()) = 1 COMMIT TRANSACTION test1 --Raise an error RAISERROR('Errormeldung',16,1)END CATCHGO

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.

Artikel In SQLServer | Kommentare (1) | Trackbacks (0)