Sie sind nun wieder eingeladen, die Diskussion spezieller technischer Probleme mit zu verfolgen. Bitte schicken Sie Fragen, Anregungen oder Antworten zu den vorgestellten Themen – ebenso wie Ihre Kritik – an unsere e-Mail-Adressen: dieter.bender@MidrangeMagazin.de oder Redaktion@MidrangeMagazin.de

Frage:

Dürfen in SQL geschriebene Trigger Updates vornehmen: auf andere Dateien, auf die getriggerte Datei selber? Wie ist das mit der Änderung des After Images, ist dies erlaubt?

Antwort:

Das Datenbank-Management-System stellt sicher (versucht es zumindest), dass ein Before-Trigger keine anderen Trigger-Ereignisse auslösen kann. Diese Prüfung gelingt immer dann, wenn versucht wird, eine SQL-Fortschreibe-Operation auszuführen oder ein SQL-Programm aufzurufen, das mit MODIFIES SQL DATA erstellt wurde. Von Versuchen zur Umgehung dieser Limitierung mit dynamischen Aufrufen anderer Programme oder mit Record Level Access ist dringend abzuraten; falls diese in einem Release-Stand möglich sind, bedeutet dies noch lange nicht, dass die Prüfung in einem anderen Release-Stand nicht zur Laufzeit zuschlägt. Die Modifikation des After Images im Buffer durch einen Before-Trigger, wird in diesem Sinne nicht als Update gewertet, sondern ist der vorgesehene Weg, eine Fortschreibe-Anforderung durch ein Trigger-Programm zu modifizieren.

Frage:

Kann man SQL-Trigger auf ein Produktions-System verteilen, indem man das generierte C-Programm transportiert und den Trigger mit ADDPFTRG aktiviert, oder muss man die SQL-Source verteilen und mit RUNSQLSTM den Trigger erstellen?

Antwort:

Das Deployment – also die Verteilung von SQL-Programmen – ist sicherlich einer der gegenwärtigen Schwachpunkte von SQL-Triggern, Procedures und Functions. Der einzige dokumentierte Weg der Verteilung besteht im Transport der Quelldateien mit den SQL-Anweisungen und der Ausführung der Quellen auf jedem Zielsystem. Zur Ausführung dieser Operationen müssen dann auf dem jeweiligen System die Voraussetzungen erfüllt sein, was die Anwesenheit des C-Compilers und der QSYSINC einschließt. Eine ähnliche Problematik tritt im Recovery-Fall auf, die insbesondere bei Teil-Wiederherstellungen nicht ausgeklammert werden kann und darf.

Frage:

Wie ist das mit der Begrenzung auf maximal 6 Trigger pro Datei und den Release-Abhängigkeiten genau?

Antwort:

Diese Begrenzung ist mit V5R1 generell aufgehoben – die Grenze von 300 Trigger-Programmen pro Datei gilt für alle Arten von Trigger-Programmen.

Frage:

Ich habe Probleme mit dem Debuggen von SQL-Triggern, wenn ich SET OPTION probiere, bekomme ich Syntaxprobleme. Wo muss dieses Statement genau stehen?

Antwort:

Das korrekte Statement für die List View lautet: SET OPTION DBGVIEW = *LIST. Für die Statement-Sicht ist die Angabe von *STMT erforderlich. Mit V5R2 kommt noch die Auswahl *SOURCE dazu, die Debugging auf Ebene der SQL-Statements erlaubt. Die Anweisung ist nur möglich für SQL-Programme und muss im Body vor der SQL-Anweisung angegeben werden – im Allgemeinen also unmittelbar vor dem BEGIN-Statement.

Frage:

Entfernt die RMVPFTRG-Datei *alle SQL-Trigger sauber oder muss das SQL-Statement „drop trigger“ verwendet werden?

Antwort:

Um mit Radio Eriwan zu sprechen: Im Prinzip ja, aber ich habe mit der SQL-Variante die besseren Erfahrungen gemacht. Das Problem besteht in der Konsistenz zwischen Repository und dem realen Installationszustand des Systems und da scheinen manche Aufgaben asynchron erledigt zu werden; jedenfalls ist es mir schon gelungen, Fehler im Repository zu erzeugen, die man zwar reparieren lassen kann, aber ein RCLSTG *DBXREF ist eine aufwändige Aktion. Die SQL-Oberfläche hat zudem den Vorteil, dass die Änderungen unter Commit durchgeführt werden können.

Den Autor Dieter Bender erreichen Sie unter dieter.bender@midrangemagazin.de