Moving EDGEBIC to a New Computer

Moving EDGEBIC to a new computer depends on your database: for the default local single-file database, back it up and carry the file across; for a shared SQL Server database, there is nothing to move because the new machine simply reconnects from the DataSource tab. In EDGEBIC by User Solutions a workstation swap is a small task, and which kind of small task depends entirely on where your data lives.

This post is the workstation-move routine. For the full reference behind the controls here, read the EDGEBIC admin guide, and for the connection details, see database connection troubleshooting. It names controls that live on the DataSource tab, never any internal path.

First, Know Where Your Data Lives

The entire difference between an easy move and a slightly-less-easy move is which database you run. Everything else follows from that one fact.

• Local single-file database. Your data lives in a database file on the machine. Moving computers means bringing that file with you, so the move is a backup-and-carry.
• Shared SQL Server database. Your data lives on a server, not on any workstation. Moving computers means pointing the new one at the same server, so the move is a reconnect with nothing to carry.

If you are not sure which you have, the DataSource tab tells you: it shows whether you are on the local database or connected to a SQL Server. Confirm that before you start, because it decides your whole procedure.

Moving a Local Database Install

For the local single-file setup, the move is three steps plus a verification.

1. Back up first. From the DataSource tab on the old machine, take the one-click export. This is a protected copy independent of the move itself, so even if something goes wrong carrying the file, you have not lost anything.
2. Install on the new machine. Install EDGEBIC on the new computer.
3. Bring the database across. Carry the database file to the new machine and point the new install at it, so it opens the same plant you had.
4. Verify. Open a known job and confirm the schedule looks right before retiring the old machine.

The one rule to hold onto is to keep the old machine, or at least the backup, until the new one is confirmed working. The backup is your fallback if anything about the move looks off. A move with a verified backup in hand is reversible; a move without one is a gamble you did not need to take.

Moving a Shared SQL Server Install

For the shared setup, the move is genuinely small, because there is nothing to migrate. The data has always lived on the server.

1. Install on the new machine.
2. Reconnect. On the DataSource tab, point the new install at the same SQL Server database the rest of the team uses. Use Test Connection to confirm it works before committing.
3. Verify. Open a known job and confirm you see the same live plan the team sees.

That is the whole procedure. Because the schedules, master data, and history sit in the shared database, the new workstation joins them by connecting, exactly as a brand-new team member's machine would. There is no file to carry and no risk of leaving data behind on the old PC, because there was never any data on the PC to leave.

What Does Not Follow: Layouts

One thing does not carry to a new computer in either case: the personal grid and panel layouts, which save per user on the machine. A fresh install starts with default layouts rather than your customized arrangement.

This is cosmetic, not a data loss. Your schedules and master data come across (with the file, or by reconnecting), and only the visual arrangement resets. Rearrange the grids on the new machine the way you like and they save themselves again, as administering grid layouts describes. If default layouts suit you, there is nothing to do at all.

The Move in One Line Each

Both are short, and both end the same way: open a known schedule on the new machine and confirm it looks right. That verification is what turns "I think the move worked" into "the move is done." For the wider set of habits that keep the database dependable through moves and upgrades, read keeping the EDGEBIC database healthy over time, and for the general context, see what production scheduling is. The full administrator reference is the EDGEBIC admin guide.