After trigger liest 'sich selber'

[Robi]

Hi,
Wir haben einen Trigger, der als after insert aufgerufen wird.
Er ruft ein Buchungspgm. Dieses ruft div. andere Programme, die u.a. den frisch geschriebenen Satz lesen. Kann es sein, das der Satz nicht gefunden wird (ab und zu), da der Vorgang des schreibens ja noch nicht 100 % abgeschlossen ist?
Wird der Job debug't wird der Satz jedesmal gefunden, läuft er ohne Debug meldet er häufig, nicht immer: Kein Satz mit diesem Schlüssel.
Mal abgesehen von dem 'Suboptimalen Programmdesign', kann das die Ursache sein ? ( V5R2, neueste PTF stand, )
(rufen heist hier CALL, nicht submit !!)
Danke
Robi

[BenderD]

Hallo,

was hat die Datei für eine Force Ratio (DSPFD)? wenn der > 1 ist, dann steht das Ding noch nicht auf Platte.

Dieter Bender

PS: vom Programm Design kann man eben nicht absehen. Lausiges Design wird mit Programm technischer Komplexität abgestraft und gutes Design (meist) durch Einfachheit und Robustheit von Lösungen belohnt!!!

Hi,
Wir haben einen Trigger, der als after insert aufgerufen wird.
Er ruft ein Buchungspgm. Dieses ruft div. andere Programme, die u.a. den frisch geschriebenen Satz lesen. Kann es sein, das der Satz nicht gefunden wird (ab und zu), da der Vorgang des schreibens ja noch nicht 100 % abgeschlossen ist?
Wird der Job debug't wird der Satz jedesmal gefunden, läuft er ohne Debug meldet er häufig, nicht immer: Kein Satz mit diesem Schlüssel.
Mal abgesehen von dem 'Suboptimalen Programmdesign', kann das die Ursache sein ? ( V5R2, neueste PTF stand, )
(rufen heist hier CALL, nicht submit !!)
Danke
Robi

[Pikachu]

Wird der entsprechende Datensatz wirklich immer korrekt geschrieben? Vielleicht tritt ab und zu ja auch ein Fehler auf und der Datensatz wird dann nicht geschrieben?

[Robi]

Force Ratio steht (natürlich) > 1

Seltsam ist aber, das andere Abläufe (Auftragskopf schreiben, Auftrags Detail erfassen liest vorher auftragskopf) die absolut ähnlich sind, nur ohne Trigger seit Jahren funktionieren. Und mit Debug krig ich's ja auch nicht hin.

Zum Design: Das ist immer solange gut, bis der Kunde alles ganz anders will als ursprünglich besprochen. Kennt doch jeder. Ich weis schon das es in diesem fall nur 'Suboptimal' ist
Robi

[Robi]

@Pikatchu
dann würde der trigge nicht anspringen

[KM]

Vielleicht hilft es ja auch direkt nach dem Schreiben des Datensatzes einen FEOD auf die Datei abzusetzen, damit der Satz sofort auf die Platte geschrieben wird. Wir hatten auch schon solche Fälle, dass sporadisch manche Sätze noch nicht geschrieben waren und somit gefehlt haben, obwohl der WRITE bereits ausgeführt wurde. Mit dem FEOD war das Problem behoben.

Gruß,
KM

[Robi]

Würd ich gerne machen, aber ein Trigger läuft an, bevor das Programm das den write macht die Kontrolle (die Möglichkeit zum feod) bekommt.

kann ich also davon ausgehen, das das Design schuld ist ?
Robi

[BenderD]

Hallo,

wieso natürlich???
Dass ein Wackelhaufen woanders funktioniert belegt nix, anderes Verhalten kann auch an unique constraints oder Indexen liegen. Die debug Argumentation schon garnicht, unter Debug läuft manches ein wenig anders als ohne, insbesondere wesentlich langsamer, deshalb muss man das auch separat starten.
Entweder reicht man den Satz durch, oder man muss forciert schreiben, oder man akzeptiert halt einen gewissen Schwund.

mfg

Dieter Bender

Force Ratio steht (natürlich) > 1

Seltsam ist aber, das andere Abläufe (Auftragskopf schreiben, Auftrags Detail erfassen liest vorher auftragskopf) die absolut ähnlich sind, nur ohne Trigger seit Jahren funktionieren. Und mit Debug krig ich's ja auch nicht hin.

Zum Design: Das ist immer solange gut, bis der Kunde alles ganz anders will als ursprünglich besprochen. Kennt doch jeder. Ich weis schon das es in diesem fall nur 'Suboptimal' ist
Robi

[Pikachu]

Ist vielleicht eine COMMIT-Steuerung vorhanden und werden ab und zu Datensätze wieder durch ein ROLLBACK entfernt, nachdem sie geschrieben und der INSERT-Trigger aufgerufen wurde?

An alle: Ist das wirklich so, dass ein neuer Datensatz unter Umständen nicht gleich nach dem Anlegen zum Lesen verfügbar ist?

[BenderD]

Hallo,

Rollback schlägt erst nach dem Trigger zu, während der Aktivität des Triggers ist der Satz da (aber gesperrt).
Bei entsprechender Blockung ist das durchaus so; gesteuert wird das durch FRCRATIO (PF und LF!!!), SEQONLY und wohl auch durch unique Indexe und anderes beeinflusst; deshalb sollte man mit so etwas sorgfältig umgehen.
Wer innerhalb von einer Transaktion (Auftragskopf und Positionen schreiben) nicht immer wieder denselben Satz lesen will (wofür es keinen vernünftigen Grund gibt!!!) und seine Keys sauber ermittelt, wozu ihn Commitment Controll fast schon zwingt, der hat diese Probleme noch nie gehabt!!!


mfg

Dieter Bender

Ist vielleicht eine COMMIT-Steuerung vorhanden und werden ab und zu Datensätze wieder durch ein ROLLBACK entfernt, nachdem sie geschrieben und der INSERT-Trigger aufgerufen wurde?

An alle: Ist das wirklich so, dass ein neuer Datensatz unter Umständen nicht gleich nach dem Anlegen zum Lesen verfügbar ist?

[Robi]

@bender
Natürlich, weil ich keine Anwendung kenne die das auf 1 hat.
zu Wackelhaufen: kein Komentar

@Pikatchu
kein Commit

und
Normalerweise (innerhalb eines Jobs) funktioniert das
Wenn ein submitteter Job sofort den frischgeschriebenen Satz lesen will ist ein FEOD nötig.
Im Trigger Fall hat ich noch nie einen Wackehaufen programmiert

Robi

[BenderD]

Hallo,

das Kriterium ist da wohl nicht der Job, sondern der offene Datenpfad (plus die Zufallskomponente, wann nun gerade die FRCRATIO voll ist) und da stützen sich zuweilen zwei schwankende Gestalten gegenseitig; wenn in einer Anwendung Dateien mit share(yes) geöffnet werden, dann funzt das, in dem Trigger kann man genau dies nicht sicherstellen und es funktioniert manchmal.
Mit Datenbank Verarbeitung haben aber solche Vorgehensweisen nix zu tun, auch wenn man das so oft sieht, dass es mancher für normal hält.

mfg

Dieter Bender

@bender
Natürlich, weil ich keine Anwendung kenne die das auf 1 hat.
zu Wackelhaufen: kein Komentar

@Pikatchu
kein Commit

und
Normalerweise (innerhalb eines Jobs) funktioniert das
Wenn ein submitteter Job sofort den frischgeschriebenen Satz lesen will ist ein FEOD nötig.
Im Trigger Fall hat ich noch nie einen Wackehaufen programmiert

Robi