The Schedule Looks Different on Two Screens: Causes and Fixes

Two people on one EDGEBIC database seeing different schedules is almost always the age of one view or a personal display setting, not a disagreement in the data. EDGEBIC by User Solutions keeps exactly one schedule on a shared database, so there are no copies to drift apart. What can differ is when each screen last read it and how each person has chosen to display it.

This post is the detailed version of that symptom in the EDGEBIC troubleshooting guide. The related case where one job reports different hours in two places is covered in the same job shows different hours in two places, and a what-if result whose dates differ from the live board is covered in a scenario result that does not match the live schedule.

What You Are Seeing

A supervisor says a job starts Tuesday. The planner says Wednesday. Both are signed into the same system, looking at what they believe is the same board, and neither can explain the other's screen. Sometimes it is a start date, sometimes a whole job that one person has and the other does not, sometimes a machine assignment.

The instinct is to look for a fault in the plan. That is almost never where the answer is.

Why It Happens

Cause 1: One view is older than the other. The single most common answer. A screen shows the plan as of when it last read it, and a scheduling run rewrites the forward plan wholesale. So a supervisor who opened a board at seven and left it open, and a planner who re-ran the scheduler at ten, are both reporting honestly about different moments. Changes made elsewhere do reach open screens automatically within a few seconds, but not every surface is on that path, and a full run is a much larger change than a single edit.

Cause 2: Somebody reopened the tab instead of refreshing. Shared lists such as work centers and products are held in memory for the length of a session, so closing a screen and opening it again can rebuild the view from the same in-memory data. It looks like a reload and can show exactly the same stale value again. Only refresh forces a re-read from the database.

Cause 3: Personal display settings differ. Colors, bar labels, which overlays are on, how lanes are grouped, and the description shown on each bar are saved per user. Two people can present the same plan so differently that the boards look unrelated. None of this changes what the engine computed.

Cause 4: Different filters, date ranges or grid layouts. Also personal. A supervisor filtered to one department and a planner looking at everything will genuinely see different sets of jobs, correctly.

Cause 5: One person has unsaved staged edits. Dragging a bar on the Gantt stages a change on that screen and does not touch the database until it is saved. Until then the other workstations are showing the unchanged plan, correctly, and the person who dragged is the only one seeing the new position. Pending edits are private until saved.

Cause 6: A run happened between the two looks. Related to cause 1 but worth separating, because the answer is different: nothing is stale, the plan genuinely changed, and the question is who ran it and when.

Cause 7: The two workstations are on different databases. The only cause on this list that is a genuine data difference. A machine that was never switched over still points at its own local single-file database and is showing a completely separate plan, which looks plausible because it was built from the same imported master data. The tell is that refreshing changes nothing and the two views disagree about things that have no reason to differ, such as which jobs exist at all.

How to Fix It

1. Both people press refresh, then compare again. Do this before anything else. It costs seconds and resolves the majority of these reports. Note that refreshing is not the same as closing and reopening the screen.
2. Stop comparing boards and compare one job. Open the same job number on both screens and read its operation dates. A vague disagreement about how two boards look becomes a specific disagreement about one number, which is answerable.
3. Ask when the last scheduling run happened. If it was between the two looks, the plan changed and neither screen was wrong, one was simply older.
4. Check for unsaved staged edits. Ask whether either person has dragged anything they have not saved. If so, that screen is the outlier by design.
5. Compare the display configuration and the filters. Same date range, same filters, same lane grouping. If the difference is which jobs appear rather than when they run, this is usually where it is.
6. Check the data source on both workstations. Same server, same database name. Do this last for a room that has been working normally, and do it first for a machine that was recently rebuilt or newly installed.

How to Prevent It

• Teach the refresh habit on day one. Before making a promise from a number on a screen that has been open for hours, refresh. This is the single highest-value habit on a shared database, and it is much easier to teach as a rule than to discover as a lesson.
• Name one owner of the scheduling run and a cadence. When the plan changes at predictable times, "is your screen older than the run" becomes a question people can answer themselves. Why only one run happens at a time covers the mechanism, and how to reschedule safely covers the run.
• Say once that display settings are personal. Colors, labels, overlays, columns and filters are yours and are supposed to differ. Knowing that stops people treating a different-looking board as evidence of a different plan.
• Verify the data source on every new or rebuilt workstation. A machine quietly running on its own local database will pass every other check and disagree about everything. Add it to your build checklist. How to install and connect EDGEBIC covers the setting.
• Ask people to save or discard staged edits before walking away. A pending drag is invisible to everyone else, so an unfinished edit left on screen over lunch is a disagreement waiting to be reported.