Trigger erst nach Commit ausführen

[cimbala]

Hallo *ALL,

gibt es eine Möglichkeit dem Trigger beizubringen, dass er bei einem Update erst NACH Ausführung des COMMIT ausgelöst werden soll?

[B.Hauser]

Was willst Du denn damit erreichen?
Trigger sind dazu da um Datenkonsistenz zu gewährleisten. Wenn der Trigger erst nach dem Commit ausgeführt wird, ist die Datenkonsistenz nicht mehr gewährleistet.

Birgitta

[cimbala]

ich habe mir gedacht das diese Antwort kommt
Der Trigger soll, nachdem ein Satz commited wurde eine Schnittstellenaktion auslösen

[andreaspr@aon.at]

Ich glaube nicht dass das möglich ist.
Und nebenbei kann ich dir auch nur davon abraten, die Datenbank mit den Programmen so eng zu verheiraten.
Eine Trennung zwischen Datenbanklogik und Programmlogik sollte es schon geben.

lg Andreas

[BenderD]

... da gibt es keine wirklich einfachen Lösungen. Man könnte die Aktion zurücknehmbar machen und bei Rollback quasi stornieren oder man könnte den dornigen Weg über die Registrierung einer Commit Ressource gehen. Weniger komplex wäre es allerdings das in die Applikation einzubauen.

D*B

[Robi]

Wenn die den Auslöser eindeutig identifizieren kannst geht es z.B. so:

Schreibe mit dem Trigger die Schnittstellen Daten in ein PF
(mit User, Jobnr ..)
Beim Rollback setzt du einen Wert in eine dtaara.
Der Trigger löscht bei gesetzter Dtaara den Satz wieder.
Dort, wo der commit stattfindet (oder am Ende des Jobs)
je nachdem wo du rankommst arebitest du die Datei ab und fütterst die Schnittstelle
Robi

[BenderD]

... das mit der DTAARA und löschen Gedöns kann man sich vollständig sparen: einfach das schreiben in diese Datei mit unter derselben Commit Definition laufen lassen, dann passiert das alles automatisch. Vom Design her bleibt das Problem, dass man nicht weiß wielange man warten soll (der Rollback könnte Stunden auf sich warten lassen); lösen könnte man dies allerdings im asynchronen Ansatz, indem man mit Locklevel read commited liest.

D*B

[Fuerchau]

Ist zwar etwas komplizierter, aber mit Commit-Ressourcen (nicht Dateiabhängig) kann man hier ggf. was steuern:

Commitment Control Exit Program

Das Problem ist sicherlich, zu erkennen, ob in der Datei entsprechende Informationen zur Verfügung stehen.

Aber ein Trigger auf der Datei kann ja eine 2. Datei befüllen, die im Rollbackfall ebenso gelöscht wird.

Die Commitressource kann also im Commit-Fall eine Aktion auslösen, wenn in der Logdatei Daten vorhanden sind.

[Robi]

einfach das schreiben in diese Datei mit unter derselben Commit Definition laufen lassen

Ja, das hatten wir zuerst auch.
Aber es gab einen Grund, (der mir nicht mehr einfällt) das zurück zu drehen (ist schon ein paar Jahre her)

Versuch's halt

Robi

[Fuerchau]

Betrachte noch mal Dieters Ansatz:
Unter Commit bleibt ein Update/Insert gesperrt, bis er Committed ist.

Wenn die Aktion also asynchron (z.B. über DTAQ) gestartet ist und dort natürlich auch unter Commit gearbeitet wird, wird bei einem "Read for Update" eben solange gewartet, bis die Sperre aufgehoben (Commited/Rolledback) ist.