SQL-Trigger an PF

[Sebastian85]

Hallo in die Runde,
erstmal vielen Dank an diese Plattform, die gute Infos und Hilfen liefert.
Nun brauche ich auch mal Eure Hilfe.
Ich möchte an eine PF einen Trigger mittels SQL anhängen. Die Datei wurde mittels DDS erstellt. Hier der gekürzte SQL-Code:

create trigger swe/insert_datei1
after insert on swe/datei1
referencing new as new_row
for each row mode db2row
begin
declare lv_cX char(3);
end

beim Ausführen des Codes bekomme ich folgenden Fehler zurück:
Nachrichten-ID . . . . : SQL7008 Bewertung . . . . . . : 30
Nachrichtenart . . . . : Diagnose

Nachricht . . . : DATEI1 in SWE für Operation ungültig.
Ursache . . . . : Ursachencode ist 18. Ursachencodes:

Der Ursachencode wird aber in den unten aufgezeigten Ursachencodes nicht mit angezeigt. Das geht nur bis Ursachencode 17.

Datei wird auch im Journal aufgezeichnet.
Bei jeder anderen Datei funktioniert das Anhängen der Trigger Problemlos.

Hat jemand eine Idee, warum das Anhängen des Triggers nicht funktioniert.
Vielen Dank im Voraus.

[Fuerchau]

Das hängt vom Aufrufer ab.
Das Journal alleine reicht ja nicht, da ein Trigger kein STRCMTCTL absetzen darf.
Jetzt gibt's 2 Möglichkeiten:
Per SET OPTION COMMIT=*NONE kommst du ohne CMTCTL aus, ggf. funktioniert der Trigger dann aber nicht, wenn CMTCTL dann benutzt wird (z.B. per ODBC).

[B.Hauser]

Sofern Commitment Control nicht gestartet ist und SQL mit Commit arbeitet (Default!) wird der STRCMTCTL (allerdings mit Default-Werten, also Commitment Scope = *ACTGRP) gestartet.

Die o.g. Fehlermeldung kommt, wenn in einer Umgebung mit Commitment Control gearbeitet wird, die Tabelle jedoch nicht aufgezeichnet wird.
Das würde ich nochmals prüfen. Vielleicht wurde die Tabelle warum auch immer aus dem Journal genommen.

Birgitta

[Sebastian85]

Vielen Danke für Eure schnellen Antworten.

@Fuerchau: Das SQL-Statement setze ich in einer Interaktive SQL-Sitzung (STRSQL) ab. Da ist das Commit-CTL = *NONE. Aber auch wenn ich den Code in eine Teildatei fülle und diese mit RUNSQLSTM ausführen will (mittels Commit=*None), bekomme ich den selben Fehler.

@Birgitta: Datei wird im Journal aufgezeichnet. Ich habe die Aufzeichnung auch bereits neu gestartet.
Datei wird derzeit aufgezeichnet . . . . . : Ja
Aktuelles oder letztes Journal . . . . . . : #SWE
Bibliothek . . . . . . . . . . . . . . . : SWe
Journalimage . . . . . . . . . . . . . . . : IMAGES *BOTH
Wegzulassende Journaleinträge . . . . . . . : OMTJRNE *OPNCLO

Wie gesagt, bei allen anderen Dateien in der Lib und dem Journal lassen sich problemlos Trigger anhängen. Diese Dateien wurden auch auf die selbe Art erstellt wie die, wo sich der Trigger nicht anhängen lässt.

[B.Hauser]

Und was passiert, wenn du unter Commitment Control (STRSQL und/oder RUNSQLSTM) arbeitest und am Ende explizit den Commit ausführst?

Birgitta

[Sebastian85]

Das hat den selben Effekt.
Wisst Ihr, was sagt der Ursachencode 18 genau aus?

[Fuerchau]

Das automatische STRCMTCTL hängt vom Release und der Sprache ab.
Auf V5R2 passiert diesbezüglich gar nichts.
Ab wann das für RPG oder ILERPG eingeführt wurde weiß ich nicht, in COBOL muss das STRCMTCTL auch vorher ausgeführt werden.
Ob das in "C" nun auch der Fall ist weiß ich nicht.
Eins aber ist sicher:
Ein Trigger darf weder Commit noch Rollback in der selben ACTGRP absetzen da dies die Transaktion der Anwendung kaputt macht.
Ein Trigger in eigener ACTGRP darf das natürlich wieder, aber nur für Dateien, die vom Trigger selber geöffnet werden, ggf. kann es hier auch zu Deadlocks kommen.

Was aber auch noch sein kann ist, dass bei Erstellen des Triggers auch noch SQL's erlaubt werden müssen wenn z.B. auch eine andere Datei verarbeitet wird.

[Pikachu]

Hier steht was zu MSGSQL7008 RC18. (http://www-01.ibm.com/support/docview.wss?uid=nas225859d1c61dce669862577e10041fb 0a)

[Sebastian85]

Hallo Pikachu,
danke für die Info. Es hat geholfen.
Es waren wirklich unterschiedliche Datumsformate in der Datei definiert.
Ich habe die Felder angepasst und es hat funktioniert.
Kleine Unschärfe, große Auswirkung.

Ich bedanke mich bei allen Beteiligten für die Hilfe.

[Fuerchau]

Da muss man doch erst mal drauf kommen.
Hätte da nicht auch ein "set Option datfmt=*iso" reichen müssen um diesem Problem aus dem Weg zu gehen?