What Changes When EDGEBIC Moves to a Shared Database

Moving EDGEBIC from one workstation to a shared SQL Server database is not a bigger version of the same thing: it changes three assumptions the software could previously take for granted, and each one gets its own replacement. In EDGEBIC by User Solutions that change is triggered by a single decision, choosing SQL Server as the data source, and everything else follows from it automatically.

This post is about what genuinely changes underneath. For the shape of the deployment itself, how several planners share one database covers what is shared and what stays personal, and planning a multi-user rollout covers the sequence.

One Decision, Not a Mode

There is no multi-user switch in EDGEBIC. The data source you choose is the whole decision.

The single-file local database is single-machine by design rather than by limitation. It needs no server and no database administrator, it is the default, and it is genuinely productive for one planner. Everything described below is deliberately inactive on it, because none of it has anything to coordinate.

Point the application at SQL Server instead and every coordination mechanism turns on at once. You do not enable them individually, and you cannot get a half-configured state where saves are protected but screens are stale. That is worth knowing because it removes an entire category of setup mistake.

Three Assumptions That Quietly Break

Running on one PC, three things were true without anybody arranging them.

Only one person could edit a record at a time. Nobody could overwrite you, because there was nobody else.

One application's memory was the truth. When you changed a work center, the same running program updated its own lists. Nothing else could have a different idea about what a work center was called.

Only one scheduling run could ever be in flight. You cannot press the button twice at once on a single machine.

Put five people on five PCs against one database and all three fail simultaneously. A colleague overwrites your edit and neither of you notices. Your work center dropdown keeps offering a machine somebody deleted an hour ago. Two people start scheduling runs that interleave their results into one incoherent plan. None of these announce themselves, which is why each one needed a mechanism rather than a warning in the manual.

What Replaces Each One

The design principle behind all three is the same: nobody gets locked out while they work. You are never blocked from opening a record because somebody else has it open, and you are never blocked from reading while a run is in progress. The check happens at the moment of the save, not at the moment of the open, which is why the software feels no heavier with five people on it than with one.

The Refused Save

The record you load carries a version number you never see. When you save, EDGEBIC asks the database to apply the change only if the record is still at that version. If a colleague saved in between, it is not, so no rows are updated and the save is refused rather than applied.

This covers the master data most worth protecting: work centers, work center groups, products, departments, customers, shifts, routings, tools, operators, skills, users and roles. It deliberately does not cover schedule rows, manufacturing orders, and the allocation records that hang off them, because the scheduling engine rewrites those wholesale on every run. A version check there would raise conflicts against the engine itself rather than against a person. Those are protected by the scheduling lock instead, which is the right tool for that job.

Why the second save is refused goes through the mechanism and its honest gaps in detail.

The Screen That Updates Itself

Every write stamps a small change marker for the family of data it touched, in the same transaction as the change itself. Every workstation reads those markers every few seconds, notices which families moved, and re-reads them.

The important detail is that the re-read merges into the list you are already looking at rather than rebuilding it. Your selection survives, your scroll position survives, and an open dropdown does not deselect itself. That matters much more on a shared database than it did before, because the refresh is now triggered by somebody else's work rather than by yours, and a planner should never be reset mid-task by an edit they did not make. How an open screen notices someone else's edit covers the timing and the exceptions.

The Run That Waits

A scheduling run is minutes of calculation followed by a short burst of writes. Two runs overlapping would produce a plan that is neither person's answer.

So a run takes a named lock that spans the whole plant. The second person to press the button waits about five seconds and then gets told plainly that a run is in progress on another workstation. That is a message, not an error, and it is deliberately fast: somebody who clicked a button deserves an answer rather than a frozen window.

The lock covers the calculation and the writing, but the database transaction covers only the writing. So while a two-minute run is in progress, everybody else keeps reading, editing and saving normally. Why only one run happens at a time explains why that split is the point.

What Does Not Change

Two things are worth stating because people expect them to move and they do not.

The engine is identical. Same routings, same calendars, same capacity arithmetic, same plan. A schedule produced on a shared server is the schedule the same data would have produced on one PC. That is exactly why proving the workflow on the local database before the move is time well spent rather than a throwaway phase.

And what is personal stays personal. Column widths, grid layouts, filters, and the way your Gantt is configured are yours and are saved per user. Two people can look at the same plan through completely different displays without touching each other's setup.

Where to Go Next

The three mechanisms are the answer to "is this safe with several people on it." The remaining work is human: deciding who runs the scheduler and when, who owns which slice of master data, and whether a server should be hosting your ERP syncs rather than whichever workstation happens to be open. What to decide before sharing one database collects those decisions in one place.

For the platform overview, the complete EDGEBIC guide maps how the pieces connect, and /edgebic covers the product as a whole.