Trigger erst nach Commit ausführen

[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.