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
This usually occurs when you reload the same table through a CDT but forget to populate that column or override it with a null and proceed to write to datastore. Could technically happen with a write to records same conditions required. the column gets initialised to null. There could be multiple reasons for this.
The easiest way to figure it out is by narrowing down which pv has the empty value and going through the history of a process instance to see at which moment the column turns null
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.
Is it happening in any special case or everytime you try to operate on this table>column?
The issue I have is that the only process running in this time frame is the one that set it to 0. I can't find a process that uses the constant for the dse table that runs in time to change it to null.
There seems to be no patter to when this happens. It doesn't happen every time only some of the time.
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.