Probleme mit einem Trigger

**peter.kinne** · 12-05-05, 11:19

Hallo,

ich habe eine Tabelle "TAB001". An dieser Tabelle hängt der Trigger "TRG001" bei dem Ereignis *AFTER *INSERT.

Der Trigger machte bisher immer das was er tun sollte. Nun habe ich ihn heute ändern müssen, weil das Feld "STATUS" mit dem Wert "2" geupdatet werden muß. Das habe ich mir ziemlich easy vorgestellt. Neue Routine vor *INLR und fertig. Leider spielt da das Betriebssystem nicht mit. Ich bekomme den Fehler "CPF5032 Satz xx in Teldatei yyy ist bereits für diesen Job gesperrt."

Und nun ? Der Update soll/muss in dem Trigger erfolgen.

Bin für jeden Tipp dankbar.

peter

**B.Hauser** · 12-05-05, 12:27

Zitat von peter.kinne

Hallo,

ich habe eine Tabelle "TAB001". An dieser Tabelle hängt der Trigger "TRG001" bei dem Ereignis *AFTER *INSERT.

Der Trigger machte bisher immer das was er tun sollte. Nun habe ich ihn heute ändern müssen, weil das Feld "STATUS" mit dem Wert "2" geupdatet werden muß. Das habe ich mir ziemlich easy vorgestellt. Neue Routine vor *INLR und fertig. Leider spielt da das Betriebssystem nicht mit. Ich bekomme den Fehler "CPF5032 Satz xx in Teldatei yyy ist bereits für diesen Job gesperrt."

Und nun ? Der Update soll/muss in dem Trigger erfolgen.

Bin für jeden Tipp dankbar.

peter

Du musst den Trigger abhängen, das Programm umwandeln und anschliessend wieder anhängen. Der Trigger kann nicht abgehängt werden, solange die Datei noch irgendwo im Zugriff ist.

Birgitta

**peter.kinne** · 12-05-05, 12:30

Hallo Birgitta,

das ist mir klar und ich habe es ja so gemacht. Denn ansonsten würde ja die neue Version des Triggers nicht auf den Fehler laufen.

Peter

**peter.kinne** · 12-05-05, 12:48

Ich konnte mir schon weitest gehend selber helfen. Und zwar habe ich den Trigger nochmals abgehängt und neu angehängt. Dabei habe ich dann das Schlüsselwort ALWREPCHG = Wiederholte Änderungen zulässig auf *YES gesetzt.

Danach läuft der Trigger und er macht genau das, was er machen sollen. Ich bin mir aber nicht sicher, ob dieses Schlüsselwort noch ander Konsequenzen hat, die ich jetzt noch nicht kenne. In der Hilfe ist wie immer nichts angegeben.

mk · 12-05-05, 12:57

Hallo

wieso ist nnichts angeben?

Wiederholte Änderung zulassen (ALWREPCHG) - Hilfetext

Gibt an, ob wiederholte Änderungen an einem Satz innerhalb
eines Auslösers zulässig sind.

Gültige Werte sind:

*NO
Wiederholte Änderungen an einem Satz innerhalb eines
Auslösers sind nicht zulässig.

*YES
Wiederholte Änderungen an einem Satz innerhalb eines
Weitere ...
F2=Erweit. Hilfetext F10=Zum Anfang F12=Abbrechen
F20=Vergrößern F24=Weitere Tasten

gruss Michael

**peter.kinne** · 12-05-05, 13:18

Zitat von mk

Hallo

wieso ist nnichts angeben?

Wiederholte Änderung zulassen (ALWREPCHG) - Hilfetext

Gibt an, ob wiederholte Änderungen an einem Satz innerhalb
eines Auslösers zulässig sind.

Gültige Werte sind:

*NO
Wiederholte Änderungen an einem Satz innerhalb eines
Auslösers sind nicht zulässig.

*YES
Wiederholte Änderungen an einem Satz innerhalb eines
Weitere ...
F2=Erweit. Hilfetext F10=Zum Anfang F12=Abbrechen
F20=Vergrößern F24=Weitere Tasten

gruss Michael

Hallo Michael,

ich gebe mich geschlagen. Hast ja Recht.

Peter

**Fuerchau** · 12-05-05, 14:50

Aus Performance-Gründen würde ich den Trigger mit BEFORE INSERT erstellen, du kannst den Puffer ändern und sparst dir das Lesen und erneute updaten.
Zumal durch deine Methode ggf. ein AFTER/BEFORE UPDATE-Trigger zusätzlich ausgelöst wird.

**peter.kinne** · 13-05-05, 06:51

Zitat von Fuerchau

Aus Performance-Gründen würde ich den Trigger mit BEFORE INSERT erstellen, du kannst den Puffer ändern und sparst dir das Lesen und erneute updaten.
Zumal durch deine Methode ggf. ein AFTER/BEFORE UPDATE-Trigger zusätzlich ausgelöst wird.

Wie kann ich den Puffer ändern ? Ich habe immer gedacht, dass ein Triggerprogramm den Wert nicht zurückgibt. Kann ich mit dir wegen diesen Thema mal telefonieren ? Das wäre bestimmt einfacher wie hier zu schreiben.

**Fuerchau** · 13-05-05, 07:46

Auf Grund der Reihenfolge der Aufrufe und Schnittstellen passiert doch folgendes:

BEFORE INSERT/UPDATE
After-Immage kann geändert werden, da erst danach der Insert ausgeführt wird.

AFTER INSERT/UPDATE
After-Immage kann zwar geändert werden, hat aber keine Auswirkungen mehr. Eigentlich nur sinnvoll um zusätzliche Aktionen auszuführen (Insert/Update anderer Dateien)

Was die Kommunikation/Nicht-Kommunikation angeht, so hast du nur bedingt Recht:
Satzpuffer geben ihre veränderten Inhalte natürlich nicht zurück, aber du kannst natürlich über *LDA o.ä. Informationen austauschen.
Zusätzlich besteht noch die Möglichkeit Abbruch-Meldungen zu senden (ESC-Nachrichten) z.b. über QMHSNDPM-API (SNDPGMMSG) um die Aktion abzubrechen.
Dies macht natürlich nur bei BEFORE-Triggern Sinn, da die Aktion ja sonst schon erledigt ist.
Ausserdem funktionieren ESC-NAchrichten auch bei ODBC, während *LDA da wohl wenig effektiv ist.

Ausserdem, wofür macht man denn Trigger ?
Um Funktionen unabhängig von den Programmen die sie auslösen auszuführen. Eine spezifische Kommunikation (ausser eben ESC-Nachrichten) macht da wenig Sinn, da Trigger ja auch z.B. per STRSQL, STRQMQRY, REXX, UPDDTA usw. ausgelöst werden.

**B.Hauser** · 13-05-05, 08:08

Zitat von peter.kinne

Wie kann ich den Puffer ändern ? Ich habe immer gedacht, dass ein Triggerprogramm den Wert nicht zurückgibt. Kann ich mit dir wegen diesen Thema mal telefonieren ? Das wäre bestimmt einfacher wie hier zu schreiben.

Hast Du Dir schon mal folgende Redbooks angeschaut?
Stored Procedures, Triggers and User Defined Functions on DB2 Universal Database for iSeries
Modernizing IBM eServer iSeries Application Data Access - A Roadmap Cornerstone

Birgitta