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

[lch02]

Hallo Miteinander,


ist es möglich in einem SQL Trigger das Schema zu ermitteln in dem der Trigger ausgeführt wird? Ich habe eine Tabelle A welche sich im Schema X und Y befindet. Es hängt jeweils der gleiche Trigger auf den Tabellen. Wenn dieser Trigger jetzt durch zB. ein Update-Event ausgelöst wird möchte ich das Schema, in dem der Trigger ausgeführt wird, in zB. eine Variable speichern.

Hat hier irgendjemand eine Idee wie man dies bewerkstelligen könnte? Ich habe auch schon im Developer Works Forum gepostet, siehe: https://www.ibm.com/developerworks/c...076ab493e3&ps=


Danke schon mal, Christoph

[Fuerchau]

Die Information um welche Tabelle in welcher Lib diesen Trigger auslöst, steht im Detail in dem Trigger-Header.

[lch02]

Wie kann ich diesen Header im Trigger selbst auslesen? Im Developer Works Forum hat mir Birgitta Hauser schon einen Tripp gegeben, der funktioniert aber leider nicht. Sie hat folgendes vorgeschlagen: GET DIAGNOSTICS CONDITION 1 sSchemaName = TRIGGER_SCHEMA;

Die interne Variable TRIGGER_SCHEMA wird aber nur befüllt wenn der SQLSTATE der Klasse 09 oder 27 entspricht. Im Prinzip will ich folgendes erreichen:

CREATE TRIGGER T_TSTFILE01_INSERT
AFTER INSERT ON TSTFILE01
.
.
BEGIN ATOMIC
DECLARE SQLSTATE CHAR(5);
declare sSchemaName VARCHAR(128);
declare retcode CHAR(5);
GET DIAGNOSTICS CONDITION 1 sSchemaName = TRIGGER_SCHEMA;
SET retcode = SQLSTATE;
insert into sometable (trgLibrary) values(sSchemaName);
END;

[Fuerchau]

Mit SQL-Native-Triggern hast du da wohl keine Chance.
Des weiteren kann man Schema- und Tablename nicht per Variable in einem Statement verwenden.
Hierfür musst du ein voll dynamisches Statement ausführen.

Allerdings ist das der falsche Ansatz.
Wenn Tabelle A in Lib A den Trigger auslöst, sollte die "sometable" in Lib A auch zur Verfügung stehen.
Das selbe gilt dann für Tabelle B in Lib B.

Entscheidend ist das SQL-Naming wo "sometable" gesucht wird und wie deine Lib-Liste zu diesem Zeitpunkt gesetzt ist.

[BenderD]

. ..wieso soll man da keine Chance haben? Man kann doch in einem SQL Trigger ein Programm aufrufen, das den callstack auswertet...

D*B

[Fuerchau]

Das ist nicht der geforderte Inhalt.
Wenn ich einen Programm-Trigger schreibe, erfahre ich im Trigger-Header durch welche Datei/Bibliothek und sogar Teildatei der Trigger ausgelöst wurde.
Ich kann eben denselben Trigger an verschiedene Dateien hängen und entsprechend reagieren.

Bei einem SQL-Trigger stellt sich die Frage der Mehrfachverwendung eigentlich gar nicht, da ich diesen ja explizit für genau eine Tabelle einrichte.

Deshalb kann ich bestimmte Informationen erst im Fehlerfall abrufen.
Vielleicht funktioniert der Trick ja, einen Fehler zu provozieren und einen Fehlerhandler zu verwenden.
Das ist dann allerdings die unschöne Art.

[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