Another User Changed This Record: Causes and Fixes

When EDGEBIC refuses a save with "this record was changed by another user", the record moved between your screen loading it and your pressing save, and refusing is the software declining to write your version over a newer one. EDGEBIC by User Solutions checks a version at the moment of the save on a shared database, which is what stops a silent overwrite.

This post is the detailed version of that symptom in the EDGEBIC troubleshooting guide. For the mechanism behind it, why EDGEBIC refuses a stale save explains what the check covers and where it does not.

What You Are Seeing

You open a work center, a product, a customer or a shift, make a change, press save, and get a message naming the record and telling you it was changed by another user, with an invitation to reload and try again. Your edit is still on screen. Nothing has been written.

The first thing to know is that this is the system working rather than failing. Nothing was lost. Your change is in front of you and somebody else's change is intact in the database, which is a much better outcome than the alternative where one of them disappears without anybody being told.

Why It Happens

Cause 1: Somebody genuinely changed it. This is the large majority of cases and needs no further explanation. A colleague opened the same work center, saved a change to it, and your screen is still holding the version from before that.

Cause 2: You are alone, and this is the second save from one open editor. The commonest confusing variant. Your screen loaded the record at one version and saved successfully, which moved the record forward, but the open editor kept holding the version it first loaded. The second save from that same open screen therefore carries a version that really is out of date, even though the only person who moved it was you. The tell is unmistakable once you know it: the first save always works, the second always fails, and there is nobody else in the system.

Cause 3: An import touched the record while your form was open. A scheduled ERP sync or a manual mask import writes a lot of records in one pass. If you had the product open across that window, the record underneath it moved. Note the asymmetry: imports themselves are deliberately not subject to this check, so the sync applied and you are the one reloading.

Cause 4: The form has been open a long time. A screen opened at nine and saved at four gives seven hours for something to change underneath it. This is the same as cause 1 but is worth naming separately, because the fix is behavioral rather than diagnostic.

Cause 5: You are deleting rather than editing. Deletes carry the same check, so removing a record somebody else has just modified is refused for the same reason and with the same shape of message.

Cause 6: What it is not. It is not a lock, and nobody is holding the record open. EDGEBIC never locks a record while somebody is editing it, so there is nothing to release, nobody to ask to close a window, and no stuck state to clear. If you go looking for a lock to break, you will not find one.

How to Fix It

1. Reload from the prompt. This is the whole answer in the normal case. It brings you the current record, including the other person's change.
2. Look at what actually changed before you re-apply anything. The other edit is information. An instance count that somebody just raised is worth knowing about before you save your description over the top of nothing.
3. Re-apply your change and save again. The second attempt carries the current version and applies cleanly.
4. If you are alone in the system, close the record and reopen it. That gets the screen a fresh version and the next save works. Then report it, because a screen that reliably fails its second save should be fixed in the screen rather than worked around by its users.
5. If it coincided with a sync, check the run history timing. A run row overlapping your editing window confirms the cause in seconds, and tells you whether to expect it again on the same schedule tomorrow.
6. Do not hunt for an override. There is no force-save and no merge, on purpose. Two people changed the same thing and a person has to decide what the result should be.

How to Prevent It

• Give each area of master data one owner. One person for work centers and calendars, one for routings, one for products, one for the order book. Two people rarely have a reason to edit the same record on the same afternoon once responsibilities are named, and this removes the collision rather than handling it well. What to decide before sharing one database covers the wider set of agreements.
• Do not leave editors open. An open form is a held version. Save it or close it before you go to a meeting.
• Decide which system is master for each field. If your ERP owns product lead times, planners should stop editing them in EDGEBIC and raise the change upstream. A field with two masters produces this message on a schedule.
• Refresh before editing a screen that has been open a while. It costs a second and it starts your edit from the current version. What the refresh button actually does explains why reopening the tab is not the same thing.
• Be careful on the screens that are not yet covered. A few edit screens, routing steps and the work center group, user and role screens among them, do not yet carry the check through, so their saves behave as last-write-wins and a collision there is silent. Single ownership matters most on exactly those screens.