Switching the EDGEBIC Datasource

Switch the EDGEBIC datasource from the DataSource tab in Settings: back up your current database, enter and test the new connection, and understand that switching repoints the application at a different database rather than copying your data into it. In EDGEBIC by User Solutions the choice between a local single-file database and a shared SQL Server database is a setting, not a rebuild, but a provider switch is one of the operations without an undo, so the order of steps matters.

This post is the datasource switch, done safely. For the full reference behind the controls here, read the EDGEBIC admin guide, and for the choice itself, see choosing a database for EDGEBIC. It names controls that live on the DataSource tab, never any internal path.

What Switching Actually Does

The most important thing to understand before you switch is what the switch does and does not do. Switching the datasource changes which database the application talks to. It does not copy the contents of your old database into the new one. It is a repoint, not a migration.

This distinction is the source of nearly every switching surprise. A planner who switches from a busy local database to a fresh SQL Server database and expects to see the same jobs will instead find an empty workspace, because the jobs live in the local file, not the new server. Knowing this up front changes the plan: you do not just switch, you switch and then populate.

Populating the target database is usually a matter of importing your master data (work centers, products, routings, and orders) through the import masks, the same flexible Excel, CSV, and database import that brings any data into the application. If IT is provisioning the SQL Server database, they may populate it directly. Either way, the data has to arrive in the target before the target is useful.

The Safe Switch, Step by Step

Because a provider switch has no undo, do it in a deliberate order rather than all at once.

1. Export a backup first. From the DataSource tab, take a one-click export of your current database. This is your guaranteed way back to exactly the state you were in before the switch.
2. Enter and test the new connection. Enter the SQL Server server and database details, then use Test Connection to confirm they work without committing. A wrong server name caught here is a typo; caught after the switch it is the recovery window for everyone.
3. Populate the target. Make sure your master data and jobs are present in the new database, by import or by IT.
4. Apply the switch and verify. Point the application at the new database, then open a known job and confirm the schedule looks right.

Each step removes a risk the next step would otherwise carry. The backup makes the whole thing reversible. The test makes the connection certain. Populating first makes the switched-to database useful. Verifying makes the switch trustworthy.

Switching for a Whole Team

Moving a team from a pilot to a shared server is the most common reason to switch, and it deserves a note. Each planner's application has its own DataSource setting, so switching the team means switching each machine to the shared server. The shared SQL Server database is populated once (it is shared), so the data work happens a single time, and then each seat repoints to it and verifies.

The pilot's local file does not vanish when you switch; it stays as a snapshot from before the move. Keep it. If the shared plan hits a snag, you can repoint back to the local database and pick up from the pilot state while you resolve the server issue. The broader rollout is covered in moving from single user to a shared server.

Switching Back

Switching is reversible in the sense that you can repoint the application back to the local database from the DataSource tab whenever you want. What does not automatically follow you is any work done on the server database after the switch. That data lives in the server database. If you repoint away from it without exporting it first, you leave that work behind on the server.

So the rule for switching back is the same as switching forward: back up the database you are leaving before you leave it. The export you took before the original switch protects the pre-switch state; an export of the server database protects the work you did there. With both, you can move between the two setups without ever stranding data.

The One Habit That Makes It Safe

Everything in this post reduces to a single habit: export before you switch, and understand that a switch repoints rather than copies. Do those two things and a datasource switch is a routine setting change with a clear undo. Skip them and it is the operation most likely to surprise an administrator who assumed the data would follow the connection.

For the connection problems a switch can surface, read database connection troubleshooting, and for the wider context of finite capacity planning on either database, see finite versus infinite capacity scheduling. The full administrator reference is the EDGEBIC admin guide.