How an Open EDGEBIC Screen Notices Someone Else's Edit

On a shared database, a change made on one workstation reaches every other open EDGEBIC screen within a few seconds, and nobody has to press anything for it to happen. EDGEBIC by User Solutions does this with a small change marker written alongside every save and a short polling cycle on each workstation, which is a plainer mechanism than it sounds and a much more reliable one than the obvious alternatives.

This post is about that mechanism: how a change is announced, how quickly it lands, and why the refresh does not disturb what you were doing. For the wider picture of what changes on a shared database, read what changes when EDGEBIC moves to a shared database.

The Problem Being Solved

On one workstation this was never a question. If you renamed a work center, the same running application updated its own lists, because there was only one copy of anything.

With five workstations there are five copies of the lists in memory, and four of them are now wrong. The specific failure this causes is quiet and nasty: a planner builds a routing against a machine somebody deleted an hour ago, or promises a date against an order quantity that was changed at lunchtime. Nothing looks broken. Stale data looks exactly like current data.

How a Change Announces Itself

Every write in EDGEBIC stamps a small change marker for the family of data it touched, and it does so inside the same transaction as the change itself.

The families are coarse on purpose: work centers, products, customers, departments, shifts, holidays, routings, schedules, manufacturing orders, sales orders, quotes, capacity overrides, security, integration definitions, scheduling policy. Renaming one work center marks the work center family as having moved. Nothing about the marker says which record changed or how, and it does not need to.

Two details in that sentence carry weight. The marker rides the same transaction as the data, so it can never become visible before the change it announces. And it is a fresh, meaningless stamp rather than a counter that ticks upward, which is what makes it safe when two people write at nearly the same moment: a counter can collide and lose a change permanently, whereas two different stamps cannot be mistaken for the one a workstation already saw.

How a Workstation Notices

Each workstation reads the markers on a short cycle, roughly every five seconds, and compares them against what it last saw. Anything that differs gets re-read.

That is one small query per cycle regardless of how busy the plant is, which is why a room full of workstations does not put meaningful load on the server. Each one also starts its cycle at a slightly random offset so they do not all tick in lockstep.

One behavior at startup is worth knowing: the first read after the application launches only establishes a baseline and refreshes nothing. Without that, every application start would trigger a full refresh of everything, which is expensive and pointless. So the first cycle is quiet and the second one onward does the work.

If a refresh fails, that family keeps its old marker rather than being written off, so the next cycle tries it again. A transient network blip costs you a few seconds, not a stale list until the next time somebody happens to edit that family.

Why Your Selection Survives

This is the part that decides whether the feature is pleasant or infuriating.

When a family is re-read, the new data is merged into the list you are already bound to rather than the list being emptied and rebuilt. Rows that changed update in place, rows that vanished are removed, rows that appeared are added, and everything else is left exactly as it was.

The consequence is that your grid selection stays selected, your scroll position stays put, and a dropdown you have open does not deselect itself under your cursor.

That is not a nicety. Before the shared database, a refresh only ever followed something you did, so a reset was tolerable. Now a refresh can fire because a colleague two rooms away saved a customer, and a planner being reset mid-task by work they did not initiate would be unacceptable. The merge is what makes automatic updating safe to leave on.

What Arrives, and How Precisely

The families are coarse, so what arrives is sometimes broader than the change that caused it.

The capacity override row is the honest one. A remote override edit arrives as a general schedule refresh rather than as a precisely targeted update, because the fine detail of which day and which work center cannot be reconstructed from a coarse marker. The result is correct, just broader than strictly necessary.

It Covers Bulk Operations Too

The heaviest operations in the product are the ones most worth propagating: clearing a schedule, deleting a customer along with everything that referenced it, wiping a data table. These write in bulk rather than record by record, and they stamp their change markers explicitly so that other workstations learn about them the same way.

That matters because a deletion is exactly the case where a stale list is dangerous. Without the marker, every other workstation would keep offering a customer that no longer exists, with no error and no clue, until somebody restarted the application.

Where the Backup Sits

Automatic updating is the primary path and it is cheap. It is not, and is not meant to be, a guarantee that covers every surface in the product.

A screen reading from a local file rather than the database is outside it. A surface whose data is loaded when you open it does not need it. And any path that somehow fails to signal leaves you looking at something old with nothing to tell you so.

That is precisely why the manual refresh button exists as a deliberate backup, and why it does something a reopened tab does not. What the refresh button actually does covers that difference, which is less obvious than it sounds.

The Practical Upshot

Two things to tell a planning team on the day they move to a shared server.

Lists updating themselves is normal and is the system working, not a glitch to report. And if a screen looks like it has not moved in a while and you are about to make a decision from it, press refresh first. That habit costs a second and removes the single most common cause of two people disagreeing about what the plant is doing.

For the save side of the same story, read why EDGEBIC refuses a stale save. The complete EDGEBIC guide maps how the pieces connect.