At the end of every shift I add a new row in a db table with new values of zero. Sometimes a new row will be added and the old values, (previous shift’s data), will carry over into the new row. See below:
INSERT INTO station_cycle_update_3_30
(DUMMY_1, DUMMY_2)
VALUES (0,0)
I’ve tried a few things, but can’t nail this one down. This is random and does not happen too often. I have about six action items running within the same group being triggered by the same update trigger. One action item out of the six within the group will have this issue, and the other items are good. Any ideas on what could be causing this?
And you have other groups that are set to update the last row of each table with the current values, correct? It sounds like what’s happening is that purely by chance, the new row is being inserted right before the update group writes it’s values, and so it’s ending up with the values that were intended for the previously last row. Does this sound possible?
Unfortunately this is a bit of a problem for these types of setups, and is something that we want to make more user friendly soon. In the mean time, you have a few options:
If your update last group doesn’t currently have a trigger, you can make it trigger on the opposite of your insert group- that way, it won’t run that one cycle that the update occurs.
If you only have 6 groups, it might be fairly easy to set it up to use Store/GetVariable to coordinate which row should be updated, instead of relying on just “last row”. To do this:
a) In your insert group, add an action item that runs after the insert action item that does something like:
StoreVariable("GroupA_ID",executeScalarQuery("select max(table_ndx) from table"))
b) In your update group, create a run-always action item that gets the value:
GetVariable("GroupA_ID",-1)
c) Change your update group to “custom” mode, with the where clause:
table_ndx={LastIdActionItem}
Hope this gives you some ideas, let me know if anything isn’t clear.
You have it right Colby, both writes are happining at the same time. I was actually just checking an earlier post with someone having the same issue. I am using an OPC item as an event meter which is acting as a dynamic counter, and believe I will have to try your option #2.