This error is received when trying to update the table based on a button click. This table is used to print shipping labels through bartender. A fellow developer and I have tested this and it occurs when two users are in the table/form even if they are in two separate sales orders. The label is printed from the sales order line. There is a button that will increase the reel number and reset some fields. This table is also written to history for reporting and reprint purposes. However, the history table writing doesn’t seem to be the case as it is complaining about another user writing to the same table of MJMFinShipLabel. We need to be able to have multiple users print from this form and do not know what property needs to be set or what needs to be written for this table to allow that.
If two users loads the same record at the same time and then try to write conflicting changes, this check protects the system from data loss. If it wasn’t there, the second update would overwrite changes done by the first update and you would end up with inconsistent database.
You’ll have to redesign your solution. You have quite a few options.
One solution is not loading the record to be updated to the form. Select it for update just before the update, update the data and write the record immediately to the database. This won’t completely rule out conflicts, but it’ll greatly decrease the probability.
You could even use pessimistic locking, which would prevent conflicts completely, but the price is performance degradation. When one user locks the table for update, all other sessions with similar requests must wait. It’s crucial keeping transactions short-lived if you use this approach.
Or you can avoid the whole problem by using a more suitable database design. Do all users really have to update the same resource? For example, instead of updating a counter field, you could create a record in a related table. To get the counter, you would simply count records related to the given label.