Die Transaktion endete mit dem Trigger. Der Batch wurde abgebrochen.

[juergen]

Hi,
kann mir jemand sagen, ob ich bestimmte Info- bzw. Fehlermeldungen von SQL 2005 unterdrücken kann.
Hintergrund der ganzen Geschichte ist, dass der SQL-Server ab Version 2005 jetzt zusätzliche Informationsmeldungen mir RAISERROR wirft, wenn z.B. ein ROLLBACK im TRIGGER ausgeführt wird.
Unter http://technet.microsoft.com/de-de/l.../ms187844.aspx wird zwar von der Verwendung von ROLLBACKS in TRIGGERN abgeraten, jedoch kann ich deswegen nicht unsere komplette Anwendung umbauen.
Da unsere Client-Anwendung jedoch auf diese RAISERROR's reagiert, sehe ich im Client nicht mehr meine eigene Fehlermeldung, sondern nur die letzte Info-Meldung der 2005er Datenbank.

Beispiel:

RAISERROR 50000 'Mein Fehler'
ROLLBACK TRANSACTION

in einem TRIGGER liefert folgende Meldungen:

Meldung 50000, Ebene 16, Status 1, Prozedur ___testJB, Zeile 12
Mein Fehler
Meldung 3609, Ebene 16, Status 1, Zeile 1
Die Transaktion endete mit dem Trigger. Der Batch wurde abgebrochen.

--> Der Client zeigt aber nur Meldung 3609 an, nicht meinen 50000er Fehler.

Wie kann ich diese 3609er Infomeldung unterdrücken, ohne den Client zu verändern?
Danke für eure Unterstützung.

[O. Helper]

Hallo Juergen,

ich nehme an, es handelt sich um einen AFTER-Trigger, richtig?

Die m.E. sinnige Alternative wäre ein INSTEAD OF Trigger, in dem Du entscheidest, ob ein INSERT/UPDATE/DELETE durchgeführt werden darf oder nicht, dann kommst Du gänzlich ohne ROLLBACK aus.
Im Fall, das das DML nicht ausgeführt wurde, kannst Du Dein RAISERROR werfen ... oder nicht.

Olaf

[juergen]

Hi Olaf,
danke für deinen Tip, leider klappt das ganze nicht so wie (von mir) gewollt.
Zum einen haben wir noch in den Triggern Aufrufe von Stored Procedures, die evtl. auch ein ROLLBACK durchführen; zum anderen stellt sich mir die Frage, wer denn jetzt wirklich mein Update durchführt, wenn im INSTEAD OF Trigger keine Fehler festgestellt werden.
Ich bin bisher devon ausgegangen, dass ich INSTEAD OF Trigger als Ersatz für das eigentliche Update/delete nutze.
Noch Zur Info: Wir haben hier hunderte von Triggern, die u.a. auch Teile unserer Business-Logik beinhalten, welche seit der Version 6.5 vom SQL-Server gewachsen sind. Diese "neu" zu erstellen ist mehr als aufwändig, weil die meisten auch sehr umfangreich sind.
Die einzige Möglichkeit die ich zur Zeit sehe ist eine "verbesserte Fehlerbehandlung" z.B. mittels TRY...CATCH, um diese zusätzliche Meldung umgehen. Eine Inhaltliche Änderung der Trigger (hiermit meine ich unsere Business-Logik) würde den Projektrahmen sprengen.

Wenn du oder jemand anderes noch einen Tip für mich habt, nur her damit.
Danke

Jürgen

[O. Helper]

Hallo Jürgen,

den INSTEAD OF Trigger hast Du richtig verstanden, er wird statt des eigentlichen DML durchgeführt. Wenn die Aktion laut BL in Ordnung ist, muss der Trigger das DML dann selbst durchführen, also z.B. den Datensatz einfügen; sonst würde nichts passieren.

Ok, eine historisch gewachsene Struktur nachträglich zu ändern, ist nicht nur aufwändig, sondern auch schwer und fehleranfällig; insbesondere wenn es von anfang an nicht richtig konzeptioniert wurde (erst alles in die DB feuern und hinterher entscheiden, ob es richtig ist ... ich weiß ja nicht).
Wie wird es überhaupt gehandhabt, wenn mehrere Datensätze zugleich geändert werden, aber nur einer von der BL als fehlerhaft erkannt wird; komplettes Rollback auf alles (geht ja auch nicht anders)?

Unterm SQL 2005 bietet es sich dann wirklich noch an, der Fehler der SP über TRY/CATCH abzufangen.

Olaf

[juergen]

Hi Olaf,
hast du evtl. eine Idee, wie ich den Fehler im Trigger "unterdrücken" kann ?
Meines Erachtens wird der Fehler erst nach Beendigung des Triggers geworfen.
Beispiel:

ALTER TRIGGER [___testJB]
ON [dbo].[____testJB]
FOR UPDATE
AS
BEGIN
BEGIN TRY

RAISERROR 50000 'Mein Fehler'

END TRY
BEGIN CATCH

ROLLBACK TRANSACTION
print 'letzte zeile - wo kann ich jetzt den Fehler abfangen ???'

END CATCH
END

Antwort von SQL2005:
letzte zeile - wo kann ich jetzt den Fehler abfangen ???
Meldung 3609, Ebene 16, Status 1, Zeile 1
Die Transaktion endete mit dem Trigger. Der Batch wurde abgebrochen.

[O. Helper]

Ach so, ich dachte die SP liefert den Fehler, den könntest Du abfangen.

Den hier nicht und Du hast den Link zur Onlien-Doku genannt und dort steht:

Wenn die Ausführung eines Triggers mit @@TRANCOUNT = 0 abgeschlossen wird, tritt ein Fehler 3609 auf...

Könntest Du nur den Code in eine SP auslagern, nur dort kommst Du nicht an die virtuellen INSERTED/DELETED Tabelle ran, die existieren nur innerhalb des Triggers.

Da fällt mir sonst auch nichts weiter zu ein als den Code des SQL Server BusinessLogik oder den vom Client zu ändern, das der den Fehler ignoriert.

Olaf