READ AFTER TRIGGER

[USDAVIS]

Moin, moin,

ich hab' da mal 'ne Frage zum Ablauf eines READ AFTER Triggers.

Wir möchten in unserer Applikation in etlichen Anzeigeprogrammen ausgesuchte Felder (FELD1, FELD2 u.s.w) aus einer Stammdatei FILE1 anders darstellen, z.B. 5% auf FELD1 aufschlagen.

Um nicht jedes Programm gesondert ändern zu müssen, hatten wir uns überlegt einen Trigger (READ *AFTER) einzusetzen.

Das sollte dann so ablaufen:

1. Programm fordert Leseoperationen auf FILE1 an.
2. Der DB2-Manager ruft den Trigger für FILE1 auf.
3. Das Triggerprogramm ändert die Werte von FELD1 u.s.w., wenn das aufrufende Programm zu den Programmen gehört, die geänderte Werte sehen sollen.
4. Programm erhält die geänderten Werte.

Im Prinzip funktioniert das auch. Nur kommen die geänderten Werte nicht beim Programm an.

Kann es sein, das der READ *AFTER erst abläuft, nachdem der Eingabepuffer des aufrufenden Programm bereits gefüllt ist und die vom Trigger geänderten Werte nicht an das Programm zurückgegeben werden können?

Ich hoffe, das Problem ist einigermaßen verständlich geschildert worden.

Gruss
Ulli

[Fuerchau]

Das ist korrekt, denn stell dir vor, das Programm, dass die geänderten Daten liest und nichts davon weiß, würde diese wieder zurückschreiben.

Ausserdem läuft der Trigger ja grundsätzlich ab.
Du müsstest also im Trigger feststellen, von welchem Programm du aufgerufen wurdest um zu entscheiden, ob Daten geändert werden sollen, denn ein Programm dass nur einen blöden CHAIN/UPDATE macht um die Satzsperre wieder aufzuheben, würde die durch den Trigger veränderten Daten wieder zurückschreiben.

Du kannst dir also ausrechnen, wann dein 5%-Aufschlag zu einem Feldüberlauf führt.

Fazit:
Ganz schlechter Programmansatz.

[USDAVIS]

Danke für die Antwort. War mir nicht so ganz klar, wie der READ-Trigger arbeitet.

Der Programmansatz ist aber schon o.k., denn:

Wir stellen im Trigger fest, von welchem Programm er aufgerufen wurde (da gab's hier im Forum ein gutes Beispiel von Birgitta Hausser) und machen die Änderung nur dann, wenn das aufrufende Programm ein reines Anzeigeprogramm ist.

Schade. Hätte uns eine Menge Programmierarbeit gespart. Statt einen Trigger zu programmieren, müssen nun dutzende Programme angepasst werden.

[RobertMack]

Statt einen Trigger zu programmieren, müssen nun dutzende Programme angepasst werden.

Oder man füllt ein Duplikat der Datei in der QTEMP und wirft eine Überschreibung (wenn's die Datenmenge zuläßt)...

Nachtrag: bei größeren Datenmengen einen permanenten Zwilling der Datei via Trigger pflegen und nur OVRDBF...

[andreaspr@aon.at]

Oder man füllt ein Duplikat der Datei in der QTEMP und wirft eine Überschreibung (wenn's die Datenmenge zuläßt)...

Nachtrag: bei größeren Datenmengen einen permanenten Zwilling der Datei via Trigger pflegen und nur OVRDBF...

wenn schon würde ich ein view erstellen, indem die 5 % dazugerechnet wird und dann mit OVRDBF das view mit dem pf überschreiben.

allerdings müsste da auch in jedem pgm eine anpassung vorgenommen werden. hätte jedoch den vorteil, dass eine änderung zb auf 6 % später viel einfacher zu verwalten wäre.

[USDAVIS]

@andreaspr, @RobertMack,

Danke für die Denkanstösse.

View geht wohl nicht, da wir (nicht lachen) noch einige RPG36-Programme haben, die auch von der Änderung betroffen sind - unser WWS ist "historisch gewachsen". Ausserdem fehlt uns jegliche Erfahrung mit SQL-Tables, -Views und Indexe.

Die Idee mit dem Duplikat ist nicht schlecht. Die Stammdatei hat allerdings ca. 219 Felder, 30 logische Sichten und 500.000 Datensätze, die alle dupliziert werden müssen. Könnte Performance-Probleme geben.

Wir erstellen jetzt ein kleines Tool, das die betreffenden Felder nach einem Lesezugriff ändert und bauen das in die Programme ein. Thema ist damit erledigt.

Nochmals vielen, vielen Dank für die Antworten.

Gruss
Ulli