Trigger und journal

[BenderD]

So habe ich es jetzt auch gemacht.
Aber es bleibt noch eine Unschärfe, die mich interessiert, wie das so in der Praxis umgesetzt wird.

STRCMTL ist gemacht
PGM A hat mehrere Dateien unter Commit, aber nicht die Datei, wo der Trigger hängt
durch eine Dateioperation wird der Trigger ausgelöst
Das Trigger Programm würde vermutlich abbrechen, weil der STRCMTL aktiv ist, aber nicht die Datei des Triggers unter commit läuft

Prinzipiell könnte man dies auch als Programmfehler abstempeln, aber ausschließen kann ich es halt auch nicht.

Man müsste erkennen, ob die Datei in dem Trigger Programm unter Commit läuft. Den API's vertraue ich da nicht wirklich.

... wer hat denn diesen Verhau angerichtet? Jetzt wundert es mich auch nicht mehr, dass weder der Trigger Buffer, noch QTNRCMTI die passende Information liefert. Dasselbe Programm läuft mal unter commit, mal nicht und wenn es unter commit läuft, dann wird eine Datei mal mit, mal ohne commit geöffnet und dann hänge ich noch einen Trigger an diese Datei, der damit zurecht kommen soll.
Warum nehmt ihr das Feld für den User nicht einfach in die Datei auf und lasst es von der Datenbank pflegen?

D*B

PS: Sauberer wäre es allerdings diesen Huddel zu bereinigen!

[Fuerchau]

Ja und dann auch nicht die Fälle vergessen, bei denen am SQL noch ein "with nc" hängt.
Z.B. "insert into table bla values(.....) with nc".

[itec01]

... wer hat denn diesen Verhau angerichtet? Jetzt wundert es mich auch nicht mehr, dass weder der Trigger Buffer, noch QTNRCMTI die passende Information liefert. Dasselbe Programm läuft mal unter commit, mal nicht und wenn es unter commit läuft, dann wird eine Datei mal mit, mal ohne commit geöffnet und dann hänge ich noch einen Trigger an diese Datei, der damit zurecht kommen soll.
Warum nehmt ihr das Feld für den User nicht einfach in die Datei auf und lasst es von der Datenbank pflegen?

D*B

PS: Sauberer wäre es allerdings diesen Huddel zu bereinigen!

Genau das haben wir ja, ein User Feld in der DB, die durch den Trigger gefüllt wird. Hatte ich ganz am Anfang geschrieben.
Ich hatte mein Beispiel zuvor ja als Fehler abgestempelt (wir haben das so nicht programmiert), aber dennoch wollte ich nur wissen, ob man im RPG erkennt, ob eine Datei gerade unter commit läuft.
Aber auf jeden Fall ist mit den Triggern unter commit nicht zu spaßen, ganz besonders wenn mal so (SQL commit) oder so (RPG commit) gemacht wurde.

[Fuerchau]

Ob per SQL oder per RPG gibts tatsächlich einen Unterschied.
Wenn STRCMTCTL nicht gestartet ist, gibts beim RPG-Commit eine Abbruchmeldung.
Beim exec sql commit gibts nur einen SQLSTATE bzw. SQLCODE.

Wenn man einen Before-Update/Insert Trigger macht, braucht man ja nur den Datenpuffer zu ändern und sich um Commit nicht kümmern, was per Definition ja sowieso nicht erlaubt ist.

[BenderD]

Genau das haben wir ja, ein User Feld in der DB, die durch den Trigger gefüllt wird. Hatte ich ganz am Anfang geschrieben.
Ich hatte mein Beispiel zuvor ja als Fehler abgestempelt (wir haben das so nicht programmiert), aber dennoch wollte ich nur wissen, ob man im RPG erkennt, ob eine Datei gerade unter commit läuft.
Aber auf jeden Fall ist mit den Triggern unter commit nicht zu spaßen, ganz besonders wenn mal so (SQL commit) oder so (RPG commit) gemacht wurde.

... für ein Feld in der selben Datei reicht es aus with default(user) bei der Erstellung anzugeben und das Feld in Ruhe zu lassen, dann steht der Inhalt des special register USER beim insert und update drin und beim ROLLBACK wird das zurückgesetzt auf den vorherigen Wert. Da braucht es keine Dateioperation im Trigger, die ACTGRP ist dann Wurscht und das Sperrlevel des Triggers ist ebenfalls egal.

D*B

[itec01]

... für ein Feld in der selben Datei reicht es aus with default(user) bei der Erstellung anzugeben und das Feld in Ruhe zu lassen, dann steht der Inhalt des special register USER beim insert und update drin und beim ROLLBACK wird das zurückgesetzt auf den vorherigen Wert. Da braucht es keine Dateioperation im Trigger, die ACTGRP ist dann Wurscht und das Sperrlevel des Triggers ist ebenfalls egal.

D*B

Danke Dir, ja ich weiß, aber funktioniert bei uns nicht, weil im Falle von Barcode Prozessen mit Handscannern ein 4stelliger User stehen muss. Daher die Idee mit dem Trigger.

[Fuerchau]

Das ist ja auch legitim, aber wofür muss der Trigger wissen, ob Commit an oder aus ist?

[itec01]

Das ist ja auch legitim, aber wofür muss der Trigger wissen, ob Commit an oder aus ist?

Ich hatte es doch versucht zu erklären. Wenn das Trigger Programm es nicht weiß, dann bricht es mir ab, je nachdem ob der STRCMTL aktiv ist oder nicht. Ich möchte auf keinen Fall mit dem trigger Programm etwas festschreiben, was im Falles eines mögliches Rollbacks dann stehen bleibt.
Das Trigger Programm hat in den F-Bestimmungen den commit unter Bezugszahl. Die Bezugszahl setze ich aktuell auf 1 oder 0, je nachdem ob der STRCMTL aktiv ist oder nicht.

[Fuerchau]

Da hilft dann nichts anderes, als den Open in eine Monitor-Gruppe zu stellen und den Open mit Commit zuerst zu versuchen.
Genauso musst du die Dateien aber auch sofort wieder schließen, da beim nächsten Mal der Status ein anderer sein kann.
Performant wird das sicher nicht, da Dateien im Trigger ja durchaus offen bleiben könnten.

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.

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