Danke für die rege Diskussion.
@BenderD: Jede Tabelle hat den Trigger selbst in der Bibliothek. Also es gibt für Tabelle A einen eigenen Trigger im Schema X und es gibt für die Tabelle A einen Trigger im Schema Y. Der SQL-Code des Triggers unterscheided sich aber nicht, diesen will ich eben hinsichtlich der Ermittlung der Bibliothek generisch halten.
@B.Hauser: Wieso ich die Bibliothek brauche? Ich will bestimmte Änderungen der Daten in Tabelle A (aus dem Schema X und Y) in einer eigenen Tabelle mit protokollieren. Hier ist es für mich interessant woher diese Änderung stammt, also entweder von Tabelle A aus Schema X oder von Tabelle A aus Schema Y.
@Fuerchau: Ich habe das jetzt auch probiert selbst den Fehler auszulösen und dann mittels GET DIAGNOSTIC das TRIGGER_SCHEMA in eine Variable zu speichern. Leider funktioniert auch das nicht.
Hier nochmals ein vereinfachtes Beispiel:
Code:CREATE TRIGGER T_TSTFILE99_UPDATE AFTER UPDATE ON TSTFILE99 REFERENCING OLD AS O NEW AS N FOR EACH ROW MODE DB2SQL SET OPTION ALWBLK = *ALLREAD , ALWCPYDTA = *OPTIMIZE , COMMIT = *NONE , DYNDFTCOL = *NO , DYNUSRPRF = *USER , SRTSEQ = *HEX BEGIN ATOMIC declare sSchemaName VARCHAR(128); DECLARE CONTINUE HANDLER FOR SQLSTATE '27001' begin GET DIAGNOSTICS CONDITION 1 sSchemaName = TRIGGER_SCHEMA; end; SIGNAL SQLSTATE '27001' SET MESSAGE_TEXT = 'Request TRIGGER_SCHEMA'; INSERT INTO MYLOG (ELLIB, ELOLDVAL, ELNEWVAL) VALUES (sSchemaName, O.VALUE, N.VALUE); END;
![[NEWSboard IBMi Forum]](images/duke/nblogo.gif)



Mit Zitat antworten

Bookmarks