Trigger und journal

[itec01]

Aber noch mal auf Anfang zurück:
"und im Trigger Programm einen chain und update gemacht."

Warum machst du keinen Before-Trigger, hatte ich oben schon mal gefragt?
Dann ergänzt du die Daten nur im Datenpuffer "Before-Image" und der Write erfolgt dann nach dem Trigger.
Beim ADDPFTRG muss dann ALWREPCHG(*YES) gesetzt werden um Pufferänderungen zu erlauben.

Oh mein Gott, ich hatte Deinen Kommentar komplett überlesen. Natürlich, der BEFORE Trigger löst alles. Im Trigger Programm muss keine Dateioperation gemacht werden, es wird lediglich der Puffer verändert.
Habe es gerade umgebaut, funktioniert tadellos.
Vielen Dank für Deine Hartnäckigkeit.

[Fuerchau]

Du kannst froh sein, dass wir auf der DB2 for i sind.
Der SQL-Server kennt in all den Jahrzehnten bis heute keinen Before-Trigger.
Es gibt nur einen After-Trigger.
Dieser bekommt dann 2 zusätzlichen Tabellen für die Auswertung:
- Inserted: Sätzen die hinzugefügt wurden
- Deleted: Sätze die gelöscht wurden.
Ein Trigger wird für eine Aktion nur genau 1x aufgerufen, auch und gerade dann wenn mehrere Zeilen betroffen wurden.

Beispiel:
Bei einem "Insert into ... select from ... " enthält die Tabelle inserted eine Kopie aller Zeilen die eingefügt wurden.
Bei einem "update table set .... where ...." führt der SQL-Server keinen Update sondern einen Delete/Insert aus und anschließend wird der Trigger aufgerufen.
Nun musst du dir halt die passenden Before/After-Images per
"select * from inserted a inner join deleted b on a.Key = b.Key"
zusammen suchen und alles mit Cursor durcharbeiten.
Beachte dabei, dass die temporären Tabellen ja keinen Index haben.

Machst du dann einen erneuten Update auf die Zieltabelle wirds heftig.
Hier erstellt der SQL-Server jetzt "Satzversionen" in weiteren temporären Inserted/Deleted Tabellen und ruft den Trigger anschließend ein 2. Mal auf.
Dadurch gibts nämlich keine Rekursion sondern eine Iteration, die natürlich in der Anzahl beschränkt ist.

Also mit SQL-Server ist das alles ganz schön kompliziert.
Die Microsoft-Spezies empfehlen daher, alle Logik in SQL-Prozeduren zu kapseln und auch Trannsaktionen in diesen durchzuführen.
Damit auch wirklich nicht irgendwelche Transaktionen über Clientzugriffe die gesamte DB lahmlegen können.
Also alle Insert/Update/Delete per z.B. "call sp_MyTableInsert(p1, p2, ...)". Da ist man dann tatsächlich gezwungen z.T. sehr große Prozeduren zu schreiben, da ja eine Transaktion, wie geschrieben, durchaus zig Tabellen betreffen.

[itec01]

Ja, vom SQL Server weiß ich das, deshalb war ich auch auf den after trigger so fixiert. Vielen Dank nochmals für die Hilfe und Deinen konkreten Ausführungen.