I'm having an issue currently where a single column, very occasionally, will revert back to null soon after it is updated. I set up a trigger that tracks when alterations are made to this column. I then checked all process instances that were running at that time and finally narrowing it down further by searching for PMs that were a depended of the database constant. I find that the only PM that fits the bill is the one that updated from null to 0 in the first place. I was wondering if anyone had experienced an issue like this before. Below are some pictures showing time stamps for when updates occurred.
In both instances it is updated back to null very quickly. The first 11 seconds later the second one within the same second. Anyone have an idea of what this could be?
Discussion posts and replies are publicly visible
Using Record Types on updates could help with this issue (assuming you are updating different fields in each of the process models. You simply put the id of the record and the fields you want to update in both PMs, if you are not updating the same fields, your data will not get overwritten.
So you are saying I could replace my Write to DSE nodes with write records smart service? Is there an advantage to this? Does writing to the DSE have an issue like the one I mentioned above often?
The advantage of using Record Types over DSEs for updates is that you can specify which fields you want to update without affecting other fields.
If you wanted to do this with a DSE there were 2 ways to do it:
1. Fetch the DSE from DB, apply the updates and write back to DB.
2. Create a separate DSE pointing to the same table with the primary key and the fields you wanted to update.