Tabellenänderungen abfangen in DB2/400

[Haunted]

Hallo zusammen,

wir versuchen aktuell Änderungen die in einer Tabelle in db2/400 gemacht werden abzufangen und weiter zu verarbeiten.

Unsere aktuelle Lösung basiert auf Triggern. Hier ist nur das Problem das diese immer ausgelöst werden, auch wenn die Transaction nicht abgeschlossen ist (bei einem Rollback bzw. Fehler hätten wir fehlerhafte Daten). Hatte jemand schonmal ein ähnliches Problem, bzw. kennt eine Lösung dafür ?

Danke.

MfG

Haunted

[BenderD]

Hallo zusammen,

wir versuchen aktuell Änderungen die in einer Tabelle in db2/400 gemacht werden abzufangen und weiter zu verarbeiten.

Unsere aktuelle Lösung basiert auf Triggern. Hier ist nur das Problem das diese immer ausgelöst werden, auch wenn die Transaction nicht abgeschlossen ist (bei einem Rollback bzw. Fehler hätten wir fehlerhafte Daten). Hatte jemand schonmal ein ähnliches Problem, bzw. kennt eine Lösung dafür ?

Danke.

MfG

Haunted

... dann muss der Trigger in derselben Transaktion mitlaufen.

[Fuerchau]

Zusätzlich müssen die Dateien, in die entsprechende Informationen verarbeitet wurden im selben Journal aufgezeichnet werden, so dass im Falle eines Rollback ebenso auch diese Änderungen rückgängig gemacht werden.

Soweit ich weiß, wird aber im Rollback-Fall ein Update/Delete-Trigger aufgerufen, so dass man auch hier entsprechend reagieren kann um die Änderungen rückgängig zu machen, die ggf. nicht journalisiert wurden.

[BenderD]

Soweit ich weiß, wird aber im Rollback-Fall ein Update/Delete-Trigger aufgerufen, so dass man auch hier entsprechend reagieren kann um die Änderungen rückgängig zu machen, die ggf. nicht journalisiert wurden.

... wenn der Trigger nicht unter Commit läuft, kann er nicht sicherstellen, dass er die nachfolgende Änderung durchkriegt, da die Satzsperren dann nicht von der Transaktion gesteuert werden. (und über RI und die Wirkung von restrict müsste man evt. nochmal nachdenken...)

D*B

[Fuerchau]

Da ja von einem Rollback-Fall gesprochen wurde, nehme ich mal ganz stark an, dass die getriggerten Dateien journalisiert werden .

[Haunted]

Hallo,

danke für eure Antworten

Nun noch eins, was ich wohl schon hätte im ersten Post schreiben solln, und zwar ist der Trigger ein RPGLE Programm welches auf eine DTAQ zugreift und die geänderte relativeID zum Programm schickt damit dieses es verarbeiten kann.

Ist der zugriff auf die DTAQ in diesem fall auch durch die Transaktion gesteuert ?

[Fuerchau]

DTAQ's können nicht journalisiert werden, da man ja beliebig versenden kann.
Hier musst du mit dem verarbeitenden Programm eine Rückgängig-Aktion vereinbaren.
Der Insert-Trigger muss z.B. "NEW...." senden, ein Update-Trigger dann "UPD..." und ein Lösch-Trigger dann "DEL...".
Im Falle eines Rollback wird nach einem Insert der Delete-Trigger aufgerufen, nach einem Update wieder der Update-Trigger mit umgekehrten Immages.

Ich denke, damit kann man auch Rückgängig-Aktionen steuern.

[BenderD]

DTAQ's können nicht journalisiert werden, da man ja beliebig versenden kann.
Hier musst du mit dem verarbeitenden Programm eine Rückgängig-Aktion vereinbaren.
Der Insert-Trigger muss z.B. "NEW...." senden, ein Update-Trigger dann "UPD..." und ein Lösch-Trigger dann "DEL...".
Im Falle eines Rollback wird nach einem Insert der Delete-Trigger aufgerufen, nach einem Update wieder der Update-Trigger mit umgekehrten Immages.

Ich denke, damit kann man auch Rückgängig-Aktionen steuern.

... ich habe schon wieder und immer noch Einwände:
DTAQs kann man journalisieren, aber nicht unter Transaktionssteuerung laufen lassen.

Das mit dem hin und zurück wird nix, wer sagt denn, dass die Änderung durchzukriegen ist (Sperren! und alles ist auch nicht reversibel). Entweder man ändert das design, oder man puffert die Einträge im Programm und sendet die erst beim commit.

D*B

[Haunted]

gibt es eine möglichkeit auf commits bzw. rollbacks zu reagieren ? hab in der IBM doku nichts explizites dazu gefunden.

[Fuerchau]

Ich denke du suchst das:
Commit notify object
Example: Using a notify object to start an application

[BenderD]

... ganz so einfach ist das nicht, der Trigger kriegt den Commit nicht mit - und dann noch das Gedöns mit den Aktivierungsgruppen...
Aber, falls dich das nicht schreckt...
http://publib.boulder.ibm.com/infoce...2FQTNADDCR.htm

Möglicherweise wäre es einfacher in der Transaktion parallel den Inhalt in eine Table wegzuschreiben und den Consumer Prozess darauf warten zu lassen, ob der Satz freigegeben wird, oder verschwindet.

D*B

[BenderD]

Ich denke du suchst das:
Commit notify object
Example: Using a notify object to start an application

... damit müsste man aber in die Applikation eingreifen, das kann der Trigger nicht erledigen...