[Gelöst] Kein Rollback bei Error nach EventSubscriber
Verfasst: 23. April 2020 16:19
Hallo zusammen,
ich plage mich mit einem sehr seltsamen Phänomen herum.
Ausgangslage:
Ich habe eine Funktionalität ("Synchronisation"), welche das Event OnAfterOnDatabaseModify der Codeunit 1 abonniert.
Diese schaut in einer Tabelle nach, ob die Daten der Herkunftstabelle (die den Modify ausgelöst hat) in andere Tabellen synchronisiert werden sollen.
Die ganze Funktion ist RecRef- und FieldRef-basiert.
Grundsätzlich funktioniert diese Synchronisation hervorragend.
Wenn in einer der Zieltabellen eine Änderung nicht (mehr) erlaubt ist (weil z. B. ein bestimmter Status erreicht/überschritten ist), dann bricht die Synchronisation mit der entsprechenden Fehlermeldung ab und die Änderungen in den Zieltabellen werden zusammen mit den Änderung in der Herkunftstabelle durch den Rollback rückgängig gemacht.
Bis hierhin alles wie gewünscht.
Problem:
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.
Es erscheint in dem Fenster der Herkunftstabelle (z. B. Verkaufauftrag) die entsprechende Fehlermeldung und der eingegebene Wert in dem Feld wird nicht gespeichert.
Wenn der Anwender jetzt F5 zum Aktualisieren drückt, damit die Fehlermeldung verschwindet, dann bleibt der (unzulässige) neue Wert in dem Feld aber stehen.
Bei anderen Feldern derselben Herkunftstabelle tritt dieses Verhalten jedoch nicht auf.
Dort kann der Feldwert nach einer Fehlermeldung nicht mit dem "F5-Trick" untergejubelt werden.
Bisherige Recherche:
In dem betroffenen Feld gibt es keinen Programmcode im OnValidate-Trigger und während der gesamten Synchronisation wird auch kein COMMIT ausgeführt.
Ebenso gibt es auch keine EventSubscriber, die direkt auf das OnAfterValidate-Event dieses Feldes gehen.
EventSubscriber auf das OnAfterModify-Event der Herkunftstabelle oder gar auf OnAfterOnDatabaseModify habe ich ebenfalls untersucht und keine COMMITS gefunden.
Frage:
Was könnte der Grund für dieses "unerwartete Programmverhalten" sein, und wie kann man es beheben?
Zur Info:
Datenbank: NAVDE10.00.16177 (CU 09)
Runtime: NAV 10.00.18609 (CU11)
In einem anderen, jedoch ähnlichem Problem konnte ich herausfinden, dass eine Prüfung in dem EventSubscriber Table37-OnAfterModify implementiert war.
Dieses Event wird jedoch nach der Datenbank-Schreibtransaktion ausgeführt, daher wird für alles vor diesem Event kein Rollback mehr durchgeführt.
Durch Verschiebung der Prüfung von OnAfterModify auf das Feld-Event OnAfterValidate funktionierte der Rollback dann hervorragend.
Diese Erkenntnis bringt mir in meinem o. g. Problem jedoch nichts, da ich ja vom OnAfterOnDatabaseModify der Codeunit 1 aus starte.
ich plage mich mit einem sehr seltsamen Phänomen herum.
Ausgangslage:
Ich habe eine Funktionalität ("Synchronisation"), welche das Event OnAfterOnDatabaseModify der Codeunit 1 abonniert.
Diese schaut in einer Tabelle nach, ob die Daten der Herkunftstabelle (die den Modify ausgelöst hat) in andere Tabellen synchronisiert werden sollen.
Die ganze Funktion ist RecRef- und FieldRef-basiert.
Grundsätzlich funktioniert diese Synchronisation hervorragend.
Wenn in einer der Zieltabellen eine Änderung nicht (mehr) erlaubt ist (weil z. B. ein bestimmter Status erreicht/überschritten ist), dann bricht die Synchronisation mit der entsprechenden Fehlermeldung ab und die Änderungen in den Zieltabellen werden zusammen mit den Änderung in der Herkunftstabelle durch den Rollback rückgängig gemacht.
Bis hierhin alles wie gewünscht.
Problem:
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.
Es erscheint in dem Fenster der Herkunftstabelle (z. B. Verkaufauftrag) die entsprechende Fehlermeldung und der eingegebene Wert in dem Feld wird nicht gespeichert.
Wenn der Anwender jetzt F5 zum Aktualisieren drückt, damit die Fehlermeldung verschwindet, dann bleibt der (unzulässige) neue Wert in dem Feld aber stehen.
Bei anderen Feldern derselben Herkunftstabelle tritt dieses Verhalten jedoch nicht auf.
Dort kann der Feldwert nach einer Fehlermeldung nicht mit dem "F5-Trick" untergejubelt werden.
Bisherige Recherche:
In dem betroffenen Feld gibt es keinen Programmcode im OnValidate-Trigger und während der gesamten Synchronisation wird auch kein COMMIT ausgeführt.
Ebenso gibt es auch keine EventSubscriber, die direkt auf das OnAfterValidate-Event dieses Feldes gehen.
EventSubscriber auf das OnAfterModify-Event der Herkunftstabelle oder gar auf OnAfterOnDatabaseModify habe ich ebenfalls untersucht und keine COMMITS gefunden.
Frage:
Was könnte der Grund für dieses "unerwartete Programmverhalten" sein, und wie kann man es beheben?
Zur Info:
Datenbank: NAVDE10.00.16177 (CU 09)
Runtime: NAV 10.00.18609 (CU11)
In einem anderen, jedoch ähnlichem Problem konnte ich herausfinden, dass eine Prüfung in dem EventSubscriber Table37-OnAfterModify implementiert war.
Dieses Event wird jedoch nach der Datenbank-Schreibtransaktion ausgeführt, daher wird für alles vor diesem Event kein Rollback mehr durchgeführt.
Durch Verschiebung der Prüfung von OnAfterModify auf das Feld-Event OnAfterValidate funktionierte der Rollback dann hervorragend.
Diese Erkenntnis bringt mir in meinem o. g. Problem jedoch nichts, da ich ja vom OnAfterOnDatabaseModify der Codeunit 1 aus starte.