The autocommitted objects have been deleted from the database to prevent database corruption. These objects have defiantly been committed but are still being deleted.

Hi All PO’s are getting deleted in our system after they have been emailed to the suppliers. Not all the time but about 5 times a month ggggrrrrrrrrr. To email a purchase order you have to open an existing PO that has been created so committed already and send it. We have put a commit before the email and after the email and every time you open a PO but they still get deleted. I dont know were to look anymore and we are looking pretty bad as PO are just vanishing from the system.    Has anybody had and solved the autocommetted objects been deleted in the pasted and what did you do, as the object is defiantly defiantly been committed. This problem started in June last year but we have only picked it up now as it does not happen alot. Some autocommitted objects still existed on logout for session ''. May 2 10:05:39.304 - WARNING - Core: (2/4) Autocommitted objects are newly created objects which were not yet committed, but are inserted into the database because an associated object was committed. May 2 10:05:39.304 - WARNING - Core: (3/4) Autocommitted objects should explicitly have been committed, please check your model and apply the necessary c hanges. The autocommitted objects have been deleted from the database to prevent database corruption.Number of autocommitted objects per type which   Regards, Patrick
5 answers

After testing with simple entities setup on Mx version 7.23.3 and 8.0.0 (beta). You could also try debugging.

In the above figure I have created an entity without committing and then created another entity (committed and associated to the uncommitted entity). This results in the auto-committed object (Temporarily stored in the database).


Maybe see if your current Mendix version is changing these variable states from auto-committed to normal; if they are remaining as auto-committed even after explicitly committing – these can potentially go missing. – maybe consider upgrading to the latest Mendix version.

When debugging further with the auto committed objects. I thought I might be able to replicate auto-committed objects going missing, but these versions don't seem to reflect this issue of deleting objects even after explicitly committing.

Auto-committed objects can still get deleted though.

– but I logged out before saving the object.

and the object was no longer stored in the DB.

if I created a  new object and saved I don't get the auto-commit logs. And when debugging, the entity state changes from instantiated to normal.






Start looking at referenced objects and their delete behaviour. Because if some object has a reference to PO with the delete behaviour to also delete the PO when it gets deleted…

But indeed autocommits just sucks and no one could ever explain to me WHY these objects need to be removed from the database. Yes when I have autocommits the developer has made a mistake and great that you help him by autocommitting. But why delete those objects?





Inside the creation microflow, including a commit on the create activity of the PO object should prevent object from going into that auto-commit state (missing). – this definitely sorted out our issue with missing objects.

If you are not committing to DB on creation this is most likely setting the object to auto-commited. – as soon as the user logs out the object will be auto-deleted! 

I hope this helps, otherwise if the PO's still go missing I would suggest implementing an XML/schema export to create backup of the PO in a JSON/XML file so that it can be stored and imported again if it goes missing.


I have had an issue with this where I have found that even though the commit flag has been set on the Creation Action, if you are setting values on this newly created entity and you use a value that is another entity which is an autocommit entity, then you can lose this normal object if the user logs out. 

My issue was the above scenario and opening a page for edit with the autocommitted entity. The page had a simple Save and Cancel. Even if the user clicked Save and then logged out of the system, the normal entity was lost.


Next to the delete behaviour, also check if you commit objects from within a dataview where you also show PO's through a reference. This can also cause this annoying issue.