m_schneider hat geschrieben:Gibt es irgendwelche Try-Functions?
Timo Lässer hat geschrieben:Ich habe eine Funktionalität ("Synchronisation"), welche das Event OnAfterOnDatabaseModify der Codeunit 1 abonniert
You also should not directly subscribe to the events in these codeunits either.
Ich habe eine Funktionalität ("Synchronisation"), welche das Event OnAfterOnDatabaseModify der Codeunit 1 abonniert
Unsere Datenbank ist noch Version 2017 (10.00), da gibt es die neuen Codeunits noch nicht.Kowa hat geschrieben:Das könnte schon die Wurzel des Übels sein. Mittlerweile wurden dieses Event ja verlegt, es ist jetzt in Codeunit 49.Timo Lässer hat geschrieben:Ich habe eine Funktionalität ("Synchronisation"), welche das Event OnAfterOnDatabaseModify der Codeunit 1 abonniert
Der OnBeforeModify scheidet aus zwei Gründen aus:Jupiter hat geschrieben:Interessant wäre auszuprobieren, den Modify für die betroffene Tabelle nicht über den globalen Trigger in der CU1 sondern direkt den OnBeforeModifyEvent der Tabelle zu abonieren.
Timo Lässer hat geschrieben:Gibt es in den Microsoft-Datenbanken (Knowledge Base & Co., PartnerSource, ...) irgendwelche direkten oder indirekten Release-Notes, dass durch ein höheres CU ein solches Fehlverhalten behoben wurde?
(Nochmal zur Info: Unsere Laufzeitumgebung hat die Version 10.00.18609 alias NAV2017 CU11.)
Timo Lässer hat geschrieben:Unsere Datenbank ist noch Version 2017 (10.00), da gibt es die neuen Codeunits noch nicht.
Timo Lässer hat geschrieben:Wie soll ich denn sonst OnDatabaseModify der Codeunit 1 abonnieren, wenn nicht über das von Microsoft bereitgestellte Event OnAfterOnDatabaseModify?
Instead you should subscribe to one of the integration events which now reside next to the business logic. The reason for this is to ensure the correct ordering of events and to provide before/after events where appropriate.
While technically possible as of now, we will block this in the future which would be a breaking change for you.
Timo Lässer hat geschrieben:...Ich befürchte, dass ich wohl (oder übel) nicht darum komme, für die Fälle einer vorherigen Prüfung (die zu einem gewollten Abbruch führen darf) separate Funktionen zu schreiben, welche ich an Events der jeweiligen Herkunftstabelle binde....
Timo Lässer hat geschrieben:[...]
Leider kommt es bei einigen wenigen Fällen dazu, dass zwar die Änderungen in den Zieltabellen zurückgedreht werden, die Änderung in der Herkunftstabelle jedoch gespeichert bleibt.
[...]nicht mehr geändert werden.
Diese PrĂĽfung findet in dem OnValidate-Trigger der entsprechenden Felder in der Tabelle "Transportanforderung" statt.[...]
Da wir - soweit es irgendwie technisch möglich ist - Standard-Trigger nur per Event-Abo erweitern, haben wir in unserer Datenbank unzählige Beispiele, bei denen es zuverlässig funktioniert.m_schneider hat geschrieben:Die Frage wäre ja erstmal, funktioniert es, wenn du es so machst?Timo Lässer hat geschrieben:...Ich befürchte, dass ich wohl (oder übel) nicht darum komme, für die Fälle einer vorherigen Prüfung (die zu einem gewollten Abbruch führen darf) separate Funktionen zu schreiben, welche ich an Events der jeweiligen Herkunftstabelle binde....
Die PrĂĽfungen befinden sich dort, wo sie erforderlich sind, daher in dem Validate-Trigger der Zieltabelle.vandyke hat geschrieben:ich verstehe nicht ganz, warum die Zieltabelle schon beschrieben wird und warum sich die PrĂĽfungen in den Validate-Triggern der Zieltabelle befinden.
Es ist technisch denkbar, dass in beide Richtungen synchronisiert wird, jedoch ist durch entsprechende Programmierung sichergestellt, dass die Synchronisation nur von "Herkunftstabellennr." in die "Zieltabellennr." überträgt und in der Transaktion nicht noch die weiterführenden Synchronisationen (also von der Zieltabelle ausgehend) anstößt.vandyke hat geschrieben:Wird denn in beide Richtungen synchronisiert?
Das kann ich leider nicht bestätigen.vandyke hat geschrieben:aber es ist leider so, dass Validateänderungen über RecordRefs von NAV nicht erkannt werden.
Selbstverständlich ist OnAfterGetDatabaseTableTriggerSetup abonniert. Dort wird kurz nachgesehen, ob die übergebene TableId als "Source Table No." in der Synchronisationseinrichtung existiert und OnDatabaseModify entsprechend auf TRUE gesetzt, damit das Event OnAfterOnDatabaseModify ausgelöst wird.vandyke hat geschrieben:Bei ersterem musst du auch OnAfterGetDatabaseTableTriggerSetup abonnieren und OnDatabaseModify auf TRUE setzen.
Im OnAfterOnDatabaseModify gibt es keinen xRec.fiddi hat geschrieben:ob xRec gefĂĽllt ist oder nicht hatte ich gerade irgendwo.
In fast allen Situationen funktioniert das auch zuverlässig und der Error löst einen Rollback aus, der sich bis zu dem Modify der Herkunftstabelle auswirkt und auch nicht mit einem anschließenden F5 ausgetrickst werden kann.
Nur bei diesem einen Feld in dieser einen Tabelle kann ich den (unzulässigen) Wert nach dem Error trotzdem durch F5 in dem Datensatz abspeichern.
Ich habe sämtlichen Programmcode sowohl mittels Code Coverage, als auch mit dem Object Manager Advanced - "Search String in C/AL Code" auf explizite und implizite Commits untersucht.jm hat geschrieben:Hast du den Vorgang mal mit Code Coverage untersucht und geprüft, welche Codezeilen durchlaufen werden?
Es handelt sich um ein ganz schnödes Code[20]-Feld mit einer simplen Tabellen-Relation auf eine einfache "Code/Beschreibung"-Tabelle.jm hat geschrieben:Hat das Feld bei dem das Problem besteht einen besonderen Datentyp?
Deine Zusammenfassung stimmt exakt, nur handelt es sich nicht um das Feld "Menge" (mit viel Nachverarbeitungscode), sondern um ein "dummes" Code-Feld, welches an sich keinen Nachverarbeitungscode enthält.vandyke hat geschrieben:Um das mal zusammenzufassen:
Sorry fĂĽr die Verwirrung.vandyke hat geschrieben: Mich hat es nur verwirrt, dass es einmal heiĂźt, es steht nix im ValidateTrigger und dann befindet sich ja doch die eigentliche PrĂĽfung im ValidateTrigger.
Auf dem besagten Feld der Herkunftstabelle gibt es keinerlei direkten EventSubscriber - weder auf Tabellen-, noch auf Page-Ebene.vandyke hat geschrieben:Ich fasse daher einfach mal meine Ansatzpunkte zusammen. Die da wären:
Dem kann ich mich nur anschließen. Das wäre echt ein Traum.vandyke hat geschrieben:Was wir dringend bräuchten, wäre ein OnAfterOnFieldValidate(FieldRef) / OnBeforeOnFieldValidate(FieldRef) Event. Das wäre schön.
vandyke hat geschrieben:Was wir dringend bräuchten, wäre ein OnAfterOnFieldValidate(FieldRef) / OnBeforeOnFieldValidate(FieldRef) Event. Das wäre schön.
Timo Lässer hat geschrieben:Mit xRec(Ref) arbeiten wir in EventSubscribern nicht.
DrĂĽckt er jetzt F5, dann erscheint keine weitere Fehlermeldung und der eingegebene Wert wird gespeichert.
fiddi hat geschrieben:Das hilft nur begrenzt, und ist nur eine KrĂĽcke, welches das Problem nur verschiebt.
Nun ja, das könnte man aber eigentlich bei sämtlichen Events/Triggern sagen.
Timo Lässer hat geschrieben:...Jetzt muss ich nur noch einen Weg finden, wie ich das Flag im Falle eines Rollbacks wieder zurückgesetzt bekomme und trotzdem sicherstelle, dass die Synchronisation nicht durch ihre Modify in den Zieltabellen weitere Synchronisationen anstößt.
Timo Lässer hat geschrieben:Dieses Flag ist jedoch unabdingbar, da ansonsten während der Synchronisation bei jedem Modify in einer Zieltabelle eine weitere Synchronisation angestoßen würde, was in einer Endlosschleife enden würde.
Jetzt muss ich nur noch einen Weg finden, wie ich das Flag im Falle eines Rollbacks wieder zurückgesetzt bekomme und trotzdem sicherstelle, dass die Synchronisation nicht durch ihre Modify in den Zieltabellen weitere Synchronisationen anstößt.
Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast