Ermitteln des Schemas im welchen ein SQL-Trigger ausgeführt wird.

[BenderD]

. wer hier Probleme hat, macht sie sich selber:
- die Datei weiß immer qualifiziert wo ihr Trigger steht
- ein SQL Trigger weiß immer welche Datei (eine einzige!!!) er triggert
- wenn ich jetzt noch den Trigger da platziere, wo er hingehört (in dieselbe Lib wie die Datei), dann weiß auch der CRTDUP oder whoever was er zu tun hat!

D*B

[Fuerchau]

Einiges hat sich ja geklärt:
http://www-01.ibm.com/support/knowle...rq.htm?lang=de

[lch02]

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:

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;          

[Fuerchau]

Leider ist SQL nicht generisch.
Dein "Insert into Mylog" muss da ja auch eher qualifiziert arbeiten.

Jetzt hängt es eigentlich von deiner Umgebung ab, wie die denn eingerichtet ist.
Für SQL-Naming *SQL kann man "current Schema" abfragen, das ist dann die Default-Lib.

Für deine Änderungs-Herkunft kannst du es auch einfacher haben.
Dein Trigger bleibt so und schreibt die Änderungen in das jeweilige Log.

Per View

select 'A', a.* from a/myfile a
Union all
select 'B', b.* from b/myfile b

kannst du die Protokollsätze dann zusammenfassen.

[Xiaoguo3]

Leider ist SQL nicht generisch.

ja,ich weiß das und das ist sehr schade.






samsung galaxy s6 edge etui