mal eine Designfrage, wenn ich mir Beispiele von Insert Triggern ansehe, dann finde ich sehr oft folgendes:
IF @@rowcount = 0 RETURN;
Ich verstehe natürlich was es bewirkt, ich verstehe aber nicht, warum es jemals zu dem Fall kommen sollte. Der Insert Trigger wird getriggert, wenn etwas "geinserted" wurde. Wie kann da die @@Rowcount jemals 0 sein?
Wird der Insert Trigger verlässlich nur dann ausgeführt, wenn etwas geinserted wurde? Oder wäre auch ein Szenario denkbar wie: Fehler tritt auf, Transaktion wird zurückgerollt, Insert-Trigger-Code wurde aber schon gefeuert? Auf den M$-Seiten oder in M$SQL-Blogs werden gelegentlich Diagramme veröffentlicht, wie eine SQL-Abfrage aufgedröselt und in welcher Reihenfolge genau die einzelnen Vorgangsschritte gestartet und wie und wann sie committed werden. Vielleicht hilft das weiter.
Das wäre natürlich eine Idee. Das bringt natürlich nur was, wenn der Rollback zwischen Aufrufen des Triggers und Abfrage passiert. Knappes Zeitfenster...
... oder der Insert Trigger erfolgsunabhängig ausgeführt wird. Weil es auch bei Misserfolg was aufzuräumen geben könnte. Der "Fehler" / die Ausnahme kann ja z.B. darin bestehen, dass ich in Tabelle tblX erst was einfügen kann, wenn in Tabelle tblY bereits ein Datensatz erzeugt wurde und Teile daraus (die ID jedenfalls) in tblX übernommen werden müssen. Das kann ich vorher checken, oder ich kann den Fehler / die Ausnahme abfangen. Das kann am Server passieren, oder im Code eines Frontends. Hier wird jetzt einfach nur rausgegangen, aber ich könnte ja noch mehr machen wollen.