How Several Planners Share One EDGEBIC Database

EDGEBIC by User Solutions supports several planners working from one schedule by having every installation point at the same SQL Server database. Each person runs the application on their own PC. What is shared is the data. What is personal is the way each person's screens are arranged.

That split is the whole model, and understanding which side of the line something falls on answers most of the questions a growing team runs into.

Two Deployment Shapes

EDGEBIC connects to its data through the DataSource tab of the Settings screen, and there are two shapes.

The single-file option is genuinely zero-setup, which is why it is the default and why most evaluations start there. It is also single-workstation by design. The moment a second person needs to see the same plan, the answer is SQL Server.

Two facts about the move are worth knowing before you make it. Switching providers requires a restart, and switching does not carry your data across: the old database keeps everything and the new one starts empty. So the migration is a planned sequence, back up, switch, rebuild master data from imports, rather than a toggle. How to switch from the local database to SQL Server covers the mechanics, and choosing a database covers the decision.

What Is Shared and What Is Yours

Once you are on a shared database, this is the line.

Shared, immediately, by everyone: products, routings, work centers, departments, shifts and calendars, manufacturing orders, sales orders, quotes, inventory, schedules, and actuals. One version of each, for the whole site.

Personal to each user: grid column widths, ordering, grouping and filters, which are saved per user automatically; the display configuration of the scheduler and Gantt; and anything else about how a screen is arranged rather than what it contains.

That second list is what makes a shared system tolerable in practice. A planner who wants twelve columns on the job list and a supervisor who wants four are not fighting over one layout, because layouts are per user. Two people can also configure the Gantt entirely differently, different colors, different bar labels, different overlays, and still be looking at the same underlying schedule. Display settings change what you see; they never change what the engine computed.

Identity and Permission

Everyone signs in as themselves. That is not ceremony: it is what makes the rest of the model work.

Each person's roles decide what they can do, so a supervisor who should log actuals but never wipe data simply does not have the controls that would let them. Security events, sign-ins, failed attempts, lockouts, role changes, are recorded permanently, which is worth nothing if three people share one login and worth a lot if they do not.

The rule that follows is short: one account per person, no shared logins, and deactivate rather than delete when somebody leaves so their history stays intact.

How Fresh Is What You Are Looking At

Screens load their data when you open them. That is the single most useful thing to know about working alongside other people, because almost every "our screens disagree" conversation is really about the age of a view rather than a conflict in the data.

The dashboard is explicit about it: it does not refresh on its own, each tab loads as you switch to it, and there is a refresh control to reload on demand. Most grids behave the same way and offer a refresh. So a view left open since the morning shows the morning, and a colleague who re-ran the scheduler at ten is looking at something newer. Refreshing is the answer, and it is worth teaching as a habit on day one rather than as a discovery in month three.

One flow deliberately breaks that pattern. An open job view or the live actuals screen updates by itself when a kiosk save lands, because that is precisely the case where somebody standing at a machine would otherwise be reading yesterday.

Two People, One Record

For most of the master data a team edits day to day, a stale save is refused rather than silently applied. EDGEBIC stamps a version on a record every time it is saved, your screen carries the version it loaded, and the save checks that the two still agree. If a colleague saved first, yours is rejected and you are told which record moved, so you reload, see their change, re-apply yours, and save again. Nothing is lost and nobody is left unaware.

That protection was switched on editor by editor rather than all at once, which is the honest limit worth knowing. The main master-data screens carry it today: work centers, products, departments, customers, shifts, and the routing list header. A few others, work center groups and the user and role editors among them, still behave the older way, where the second save wins and neither person is told. The difference is nothing deeper than which editors have been moved onto the version check so far, and the remaining ones are being closed the same way.

Scheduling data is a deliberate exception rather than a gap. Schedules, orders, and their resource rows are rewritten wholesale by the scheduling engine across many paths at once, so a per-record version check there would raise conflicts in the middle of a perfectly legitimate run. Those are protected by the plant-wide hold on the run itself, described below.

Ownership is still the practical answer on top of all of it. Agree who owns which slice of the master data, one person for work centers, one for routings, one for the order book, and collisions essentially stop occurring, because two people rarely have a reason to edit the same product on the same afternoon. Where two planners genuinely share a screen, the master production schedule is the usual example, the discipline is to refresh before acting on what you see, because the version check protects the record, not your judgment about a stale number.

The older behavior, which is still what the remaining screens do, is covered in what is last-write-wins concurrency.

Coordinating the Scheduling Run

Two people cannot run the scheduler at once. EDGEBIC takes a plant-wide hold when a run starts and releases it once the run has finished writing, so the second person to click Re-Schedule is told that a run is already in progress on another workstation and asked to try again shortly. The answer comes back within a few seconds; nobody watches a frozen window for the length of somebody else's run. The hold is also released automatically if the machine holding it drops off the network, so a crash mid-run cannot lock the plant out.

Most teams still put one person in charge of the run, and that reason is human rather than technical.

A run rewrites the forward plan. Anyone who had staged Gantt edits in progress, or was reading a job list to promise a date, is suddenly working from something that moved. So the common pattern is a named owner, a known cadence, every morning, or after each batch of new orders, and a word before an unscheduled run. The reschedule safely guide covers the run itself.

Everything else parallelizes fine. Entering orders, logging actuals, building routings, running reports, quoting: several people can do all of that at once without stepping on each other, because they are touching different records.

Where It Fits

Multi-user working is a deployment decision more than a feature, and it is worth taking in the right order: get one planner producing a schedule people trust, then move to the shared database, then add the supervisors and the kiosks. Planning a multi-user rollout covers that sequence, and keeping the database healthy over time covers what changes about maintenance once a server is involved.

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

One Plan, Several People

The value of a shared database is not that several people can log in. It is that there stops being more than one answer to what the plant is doing this week. A supervisor's copy of the schedule cannot drift from the planner's, because there is no copy. What is left is a much smaller and much more solvable problem: making sure the screen in front of you was loaded recently, and agreeing who owns what.