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

[BenderD]

... ich brauche doch nur den Trigger in die Lib zu packe, wo auch die getriggerte Tabelle steckt, was auch Recovery Gesichtspunkten ohnehin die zu empfehlende Variante ist...
D*B

[B.Hauser]

Irgendwie ist mir nicht ganz klar weshalb Du die Bibliothek brauchst.
Wenn Du weißt wie das Trigger Programm heißt und mit welcher Tabelle in welchem Schema es verbunden ist, kannst Du die Trigger-Programm-Bibliothek ganz leicht aus der Catalog View SYSTRIGGERS (in Bibliothek QSYS2) ermitteln.

Beim Erstellen von SQL-Triggern werden übrigens alle nicht aufgelösten Referenzen (alle unqualifiziert angegebenen Datenbankenobjekte) aufgelöst, d.h. für alle unqualifiziert angegebenen Datenbanken-Objekte (Tabellen, Views aber auch aufgerufene Stored Procedures und UDFs) wird die Bibliothek/Schema ermittelt, in denen sie hinterlegt sind und vor der eigentlichen Umwandlung in den Source Code übernommen.

Diese Auflösung erfolgt übrigens unabhängig davon, ob mit System-Naming oder SQL Naming gearbeitet wird. Beim System-Naming wird bei der Ermittlung des Schemas die aktuelle Bibliotheksliste abgegriffen, beim SQL Naming das CURRENT SCHEMA und der CURRENT PATH.
Normalerweise wird bei System-Naming die Bibliotheksliste zur Laufzeit abgegriffen. SQL-Trigger bilden eine Ausnahme.

Das kann man auch schön über die Catalog-View SYSTRIGGERS nachprüfen.

Birgitta

[BenderD]

... ob die Brücke immer trägt? Ich würde da nicht so ohne weiteres drübergehen wollen. Letztlich generiert der SQL Trigger ein C Programm (oder hat sich das geändert?), das als externes Programm aufgerufen wird (und auch wieder Referenzen auf anderes beinhalten kann...). Sicher bin ich allenfalls, dass man mit naming *SQL und current_Schema auf der sicheren Seite ist (und verfahre bevorzugt so!).
D*B

[B.Hauser]

Zumindest ist es so dokumentiert und wenn man sich das modifizierete SQL-Statement aus dem dann der C-Code mit embedded SQL generiert wird, sieht man alle unaufgelösten Referenzen mit Bibliothek. Sollte ein Objekt nicht gefunden werden, geht die Umwandlung schief.

Birgitta

[Fuerchau]

Und trotzdem gibt es eine Lücke:
Wie kann man nun zur Laufzeit erfahren, in welcher Lib die Datei steht, für die der Trigger ausgeführt wird?
Im eigenen Trigger kann ich auch die vollständige Triggerinformation zugreifen, im SQL-Trigger eben nicht.

Die vollständige Auflösung der Objekte im Trigger ist natürlich gefährlich!
Beispiel:
Trigger A in Lib A für File A protokolliert in File B.
Da File B nicht qualifiziert ist, wird dies in A.B aufgelöst?

Nun dupliziere ich die Lib A in Lib B.
Was ist mit dem Trigger A?
Der wird zwar mitkopiert, aber steht nun in der Tabelle A in Lib B der neue Trigger?
Verweist das Protokoll des Triggers A nun auf Tabelle B.B oder weiterhin auf A.B?

[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