Why EDGEBIC Refuses a Stale Save Instead of Overwriting

When two planners edit the same record in EDGEBIC, the second save is refused rather than applied over the first, and the person who lost the race is told rather than left to find out later. EDGEBIC by User Solutions does this with an optimistic version check that locks nobody out while they work and only intervenes at the moment a genuine collision occurs.

This is the mechanism that makes a shared scheduling database safe rather than merely possible. This post covers how it works, what it protects, and where it honestly does not.

Nobody Is Locked Out

The obvious answer to two people editing one record is to lock it. Whoever opens it first owns it, and everyone else waits.

That answer is worse than the problem. A planner who opens a work center, takes a phone call, then goes to lunch, has locked a record for an hour. A workstation that crashes mid-edit leaves a record nobody can touch until somebody clears it by hand. And the vast majority of the time the lock protects against a collision that was never going to happen, because two people rarely have a reason to edit the same product on the same afternoon.

So EDGEBIC takes the optimistic route. Everyone opens what they like. Everyone edits freely. The check happens once, at the save, and costs nothing at all until two edits genuinely overlap.

How the Check Works

Every protected record carries a version number you never see and never type. Loading the record hands your screen that number along with the data.

When you save, EDGEBIC does not simply write the new values. It asks the database to apply them only if the record is still at the version your screen loaded. Two outcomes follow.

If nothing moved, the record is still at that version, the write applies, and the version steps forward by one. Your colleagues' screens will pick that change up shortly afterward.

If a colleague saved in between, the record is no longer at your version, so nothing matches, nothing is written, and the save is reported back as refused. You see a message naming the record and asking you to reload and try again.

The important property is that the check and the write are the same operation. There is no window between "check whether anybody changed it" and "write my change" in which somebody could slip in. That is why this works reliably rather than merely usually.

A Worked Collision

Two planners, Anna and Ben, both open the work center Mill-1 at nine o'clock.

Anna's change survived. Ben lost thirty seconds of typing and learned something true about the state of the plant. Nothing was silently lost, and the final record carries both changes.

Compare that with the alternative. Without the check, Ben's save writes his whole record, including the old instance count he loaded at nine o'clock, straight over Anna's change. Anna's edit is gone, nobody is told, and the discovery happens a week later when a schedule comes out wrong.

What It Covers

The check applies to the master data most worth protecting from a silent overwrite:

• Work centers and work center groups
• Products
• Departments and customers
• Shifts
• Routings and routing lists
• Tools, operators and skills
• Users and roles

That list is the shared master data a plant argues about, which is exactly where a silent overwrite hurts most.

What It Deliberately Does Not Cover

Two exclusions are on purpose and worth understanding, because both look like gaps until you see the reasoning.

Schedule rows, manufacturing orders and their allocation records. These are rewritten wholesale by the scheduling engine on every run. Putting a version check on them would mean the engine collides with itself, raising conflicts mid-reschedule that no person caused and no person can resolve. Cross-machine safety for scheduling comes from a different and better-suited mechanism: only one scheduling run may be in progress across the whole plant at a time. Why only one run happens at a time covers that.

Imports. A scheduled ERP sync or a manual mask import runs as last-write-wins on purpose. Refusing four thousand product rows because one planner had one product form open would be a far worse outcome than the race it prevents. An import is a bulk authority operation and it applies. The practical consequence is that if your ERP is the master of a field, you should stop editing that field in EDGEBIC rather than relying on a conflict check to arbitrate.

Where It Is Honestly Incomplete

A few edit screens carry the version on the way in but do not yet carry it back out and through the save, which means their saves still behave as last-write-wins. Routing steps, work center groups, and the user and role screens are in that group today.

Naming that matters more than hiding it. It means a working agreement about ownership of master data is still doing real work rather than being a belt with braces, and it means that if two people are going to share responsibility for one area, routings are the place to be most careful.

The concept in general terms is covered in what last-write-wins concurrency is.

What to Do When It Fires

The prompt asks you to reload, and reloading is the whole answer. Reload, look at what changed, re-apply your edit on top, and save again.

Do not reach for a way to force the save through. There is no merge to perform and no override to find, and that is deliberate: an automatic merge of two people's intentions is a guess, and a guess about capacity or a routing step is worse than thirty seconds of retyping.

If the message appears when you are demonstrably alone in the system, that is a different symptom with a different cause, and another user changed this record walks through it.

The Point of the Refusal

The refusal is not the software being difficult. It is the software declining to make a decision it is not qualified to make.

Two people changed the same thing. One of those changes is going to survive as written and the other needs a human to look at the result and decide. EDGEBIC picks the one that got there first, keeps it intact, and puts the question in front of the person who is still holding the other half. That is the only outcome where nobody's work disappears without anybody noticing.

For how the same shared database keeps everyone's screens current in between saves, read how an open screen notices someone else's edit. The complete EDGEBIC guide maps the wider platform.