Checksum Fehler in MRU Prozess oder “Aufgepasst beim Item-Zugriff”
- Peter Raganitsch
- Kategorie: Oracle APEX, Fehlersuche, Oracle APEX, Tipps & Tricks
Gerade bin ich über ein fast unerklärliches Phänomen gestossen, in einer bestehenden Applikation taucht auf einmal folgender Fehler auf:
ORA-20001: Fehler in MRU: row= 1, ORA-20001: ORA-20001: Die aktuelle Version der Daten in der Datenbank wurde geändert, seit der Benutzer einen Update-Prozess eingeleitet hat. Aktuelle Prüfsumme (Checksum) = "E56AD2276AAB9F00EFDB53EC1FBEA57C" Element-Prüfsumme (Checksum) = "0E933FF27E0A1EB913C83CE4D2C9E506"., update "ABC"."XY_V_TEST" set "OID" = :b1, "DESCRIPTION" = :b2,
Das tritt auf, wenn zuerst eine falsche Eingabe passiert und versucht wird zu speichern. Im Ablauf des Submit wird zuerst das Update in der DB gemacht und dann noch ein weiterer PL/SQL Process aufgerufen in dem Applikatorische Logik geprüft wird.
Aus letzterem wird eine Exception geraist und dem User angezeigt, der korrigiert daraufhin den Fehler und versucht nochmals zu speichern und bekommt dann den Checksum Fehler.
Noch weiter verwirrend ist, dass die Daten aber in der DB stehen und committed wurden, was sich dann aber gleich als Grund für den Checksum-Fehler herausstellt.
Klar, glaubt doch Apex dass die Daten nicht in der DB stehen weil im Zuge des Speicherns ein Fehler aufgetreten ist.
Was ist da eigentlich passiert?
Nun zuerst sehen wir uns die Prozesse an:
Wir sehen, dass zwischen unserem MRU-Prozess und dem Prozess in dem der Fehler erzeugt wird noch 2 weitere Prozesse liegen. Einer der beiden muss anscheinend ein Commit beinhalten oder ausgelöst haben.
Und siehe da, in einem der beiden Prozesse wird ein Item gesetzt:
Apex schreibt alle Itemzuweisungen in Prozessen im Session State fest, dazu wird natürlich ein Commit abgesetzt (Hinweis an Apex-Development-Team: bitte über autonome Transaktionen lösen).
Also aufgepasst wann und wo sie Items setzen und immer daran denken, dass dies ein Commit auslöst!
