View Full Version : After trigger liest 'sich selber'
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
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
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?
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
@Pikatchu
dann würde der trigge nicht anspringen
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
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
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
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?
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?