Es kommt \u00f6fter vor, dass man im Batch mehrere SQL-Statements ausf\u00fchren m\u00f6chte, sei es in einer Stored Procedure oder im Execute SQL-Task von SSIS.<\/p>\n
Meistens hat man folgende Anforderung:<\/p>\n
L\u00e4uft ein Statement auf einen Fehler, soll ein Rollback der Statements gemacht werden. Au\u00dferdem soll nat\u00fcrlich dem aufrufenden System der Fehler gemeldet werden.<\/p>\n
L\u00e4sst man einen Batch einfach so laufen, wird dieses Ziel nicht erreicht, da im Fehlerfall auch die Statements nach dem Statement, das den Fehler verursacht, ausgef\u00fchrt werden.<\/p>\n
Beispiel:<\/p>\n
\nset nocount on
\nselect 1
\nselect 1\/0
\nselect 2<\/p>\n<\/blockquote>\nliefert:<\/p>\n
\n\n———–
\n1<\/p>\n\n———–
\nMsg 8134, Level 16, State 1, Line 3
\nDivide by zero error encountered.<\/p>\n\n———–
\n2<\/p>\n<\/blockquote>\nIn Versionen vor SQL Server 2005 musste man die Error-Variable auslesen, etwa so:<\/p>\n
\nset nocount on
\ndeclare @fehler as int
\nset @fehler = 0
\nselect 1
\nset @fehler = @fehler + @@error
\nselect 1\/0
\nset @fehler = @fehler + @@error
\nselect 2
\nset @fehler = @fehler + @@error
\nif @fehler>0 begin
\n print ‚Ein Fehler ist aufgetreten‘
\nend<\/p>\n<\/blockquote>\nwas folgendes Ergebnis liefert:<\/p>\n
\n\n———–
\n1<\/p>\n\n———–
\nMsg 8134, Level 16, State 1, Line 6
\nDivide by zero error encountered.<\/p>\n\n———–
\n2<\/p>\nEin Fehler ist aufgetreten<\/p>\n<\/blockquote>\n
Das Problem ist, man muss die Zeile „set @fehler = @fehler + @@error“ nach jedem Statement schreiben, da sie nach jedem (!) Statement zur\u00fcckgesetzt wird.<\/p>\n
Leichter geht das in SQL 2005 mit begin try … end try – angelehnt an Konstrukte aus Programmiersprachen wie C#:<\/p>\n
\nset nocount on
\nbegin try<\/p>\nselect 1
\nselect 1\/0
\nselect 2<\/p>\nend try
\nbegin catch
\n print ‚Ein Fehler aufgetreten‘
\nend catch<\/p>\n<\/blockquote>\nAm Ergebnis<\/p>\n
\n\n———–
\n1<\/p>\n\n———–<\/p>\n
Ein Fehler aufgetreten<\/p>\n<\/blockquote>\n
sieht man, dass nach dem fehlerhaften Statement die Bearbeitung beendet wird.<\/p>\n
Nun fehlen nur noch 2 Anforderungen:<\/p>\n
Dass keine Datenmanipulation statt findet, erreicht man \u00fcber eine Transaktion, die im catch-Block zur\u00fcckgerollt (rollback) wird.<\/p>\n
Dass der Aufruf dennoch den Fehler mitbekommt, erreicht man \u00fcber einen raiserror.<\/p>\n
Das fertige Skript sieht dann so aus:<\/p>\n
\nset nocount on<\/p>\n
begin tran
\nbegin try<\/p>\n\/* hier die eigentlichen SQL-Statements schreiben *\/
\nselect 1
\nselect 1\/0
\nselect 2<\/p>\nend try
\nbegin catch
\nif @@trancount > 0 begin
\n rollback tran
\nend
\ndeclare @fehler_text nvarchar(4000)
\nset @fehler_text = ERROR_MESSAGE()
\ndeclare @fehler_severity int
\nset @fehler_severity = ERROR_SEVERITY()
\ndeclare @fehler_state int
\nset @fehler_state = ERROR_STATE()
\nRAISERROR (@fehler_text, — Message text.
\n @fehler_severity, — Severity.
\n @fehler_state — State.
\n)<\/p>\nend catch
\nif @@trancount > 0 begin
\n commit tran
\nend<\/p>\n<\/blockquote>\n","protected":false},"excerpt":{"rendered":"Es kommt \u00f6fter vor, dass man im Batch mehrere SQL-Statements ausf\u00fchren m\u00f6chte, sei es in einer Stored Procedure oder im Execute SQL-Task von SSIS. Meistens hat man folgende Anforderung: L\u00e4uft ein Statement auf einen Fehler, soll ein Rollback der Statements gemacht werden. Au\u00dferdem soll nat\u00fcrlich dem aufrufenden System der Fehler gemeldet werden. L\u00e4sst man einen … begin try in SQL-Batch-Statements<\/span> weiterlesen