PDA

View Full Version : Trigger Sql-updates



Seiten : 1 [2]

Fuerchau
10-08-17, 11:19
Halte den Prozess mal auf dem SNDPGMMSG an und schaue dir die CALL-Stack mal genau an.
Wenn das Programm im Stack nicht gefunden wird, gibts was auf die Finger.

tarkusch
10-08-17, 12:02
Aufrufstappel ist:


Art Programm Anweisung Prozedur
QCMD QSYS /04FA
ADDLIBLE TSTPGM 2100 /0034
QUOCPP QPDA /07A0
QUOMAIN QPDA /011E
1 QUOCMD QSYS /01EA
MNU01C TSTPGM 6900 /008F
MNU01R T_TSTOBJ _QRNP_PEP_MNU01R
MNU01R T_TSTOBJ 457 MNU01R
TPGM03 T_TSTOBJ _QRNP_PEP_TPGM03
TPGM03 T_TSTOBJ 2495 TPGM03
QRNXIO QSYS 49 _QRNX_DB_UPDATE
QDBUDR QSYS /0853


Update wurde vom Testprogramm TPGM03 gemacht.

Fuerchau
10-08-17, 12:57
Wie du siehst gibts noch eine Runtimeebene dazwischen, QRNXIO.
Aus OPM wird aber QDBUDR direkt aufgerufen.
Und wie siehts bei SQL oder UPDDTA aus?

Ich habe mir dafür mal eine kleine Routine geschrieben, die den CALL-Stack (API) nach oben durchläuft und das 1. Programm sucht, dass nicht in einer Q-Lib liegt und nicht mit Q beginnt.
Denn dein SNDPGMMSG kann da nicht alle Varianten durchtesten, denn man muss wirklich mit der höchsten Variante anfangen. Aber wer sagt dir denn, dass nicht durch mehrere Trigger und diversen Zwischenstufen nicht das QRNXIO sehr viel höher liegt als der aktuelle Verursacher?
Ohne eine Stackuntersuchung ist das SNDPGMMSG-Verfahren nur noch für OPM ohne SQL gültigt.

Und noch eine Variante:
Die Anwendung benutzt Filehandler-Programme. Wenn nun jedesmal der Filehandler auftaucht ist der tatsächliche Verursacher nur zu finden, wenn man den Aufrufer des Filehandlers ermittelt.
Deshalb habe ich die CALL-Stackanalyse auch in jedem Trigger individualisiert.

tarkusch
10-08-17, 13:02
Habe die von dir angegeben Variante getestet.

Hätte noch eine Frage:
Updates mit:
UPDDTA = QDZTD00001
SQL = QSQISE

gibt es sonst noch andere Ausnahmen die Updates machen können(außer Programme)?

Fuerchau
10-08-17, 13:07
QSQISE ist STRSQL.
Es gibt auch noch embedded SQL und dynamisches SQL (ODBC-Jobs).
Wie ist es bei CPYF?