How to Switch from SQLite to SQL Server in EDGEBIC

To switch EDGEBIC from the local SQLite file to a shared SQL Server database, back up the current file with Export current first, then on Settings and the DataSource tab choose SQL Server, enter the server and database, test the connection, and Apply and restart; the switch changes where data lives but does not copy your existing data across. EDGEBIC by User Solutions treats the provider switch as a settings change, so the move is low-risk and reversible, but the empty new database is the one detail that surprises people: plan the data step, do not assume it migrates.

This post covers the switch mechanics and what does not carry over. For the broader single-planner-to-team story and the habits a shared plan needs, see moving EDGEBIC from one planner to a shared server; the full task library is at the EDGEBIC how-to hub.

Before You Start

• You have a SQL Server instance name and rights to create or use a database on it. See how to connect EDGEBIC to SQL Server for the connection detail.
• You have your standard import files ready, so you can rebuild master data against the new database.
• You accept that the switch is a settings change, not a data copy. The old file stays intact as your fallback.

The Steps

1. Back up the local file first. On Settings and then DataSource, click Export on the active-connection card, or use Export current first on the switch warning card. This creates a timestamped copy so you can return to the exact data you have today.
2. Select SQL Server. Under Database provider, choose SQL Server. (PostgreSQL and MySQL are listed but not available; only SQLite and SQL Server are supported.)
3. Enter the server and database. Type the Server and a Database name. The database does not need to exist; EDGEBIC creates it on first launch.
4. Choose Windows authentication. It stores no password and avoids the per-account password pitfall. Use SQL authentication only if your server requires it.
5. Test the connection. Click Test connection. A message that the server is reachable and the database will be created is the expected result for a new database.
6. Apply and restart. Click Apply and restart. EDGEBIC restarts against SQL Server and builds the schema. The new database is empty, so it prompts you to create an administrator again.
7. Rebuild the data. Recreate your import masks and re-run your standard files for products, work centers, routings, and orders, then spot-check counts against the old file.

What Changes When You Save

How to Check It Worked

After the restart, the connection card on Settings and DataSource should show SQL Server, the server, and the database with a green Connected chip. Because the database is new, you will have just created an administrator again. Once you re-run your import masks, open Job View and confirm the rebuilt orders schedule the same way they did on the local file. When they match, the switch is complete.

Common Mistakes

Skipping the backup. Export first, every time. The old file is your fallback, and one click makes a timestamped copy before you leave it.

Expecting data to appear. The new database is empty on purpose. If the schedule looks blank, that is the switch working as designed, not data loss. Switch back to SQLite to confirm the old data is safe, then rebuild.

Rebuilding by hand instead of by mask. Your import masks re-create products, work centers, routings, and orders far faster and more reliably than typing. Prepare them before you switch.

Leaving accounts to the last minute. A new database has no users. Create roles and named accounts before the other planners arrive, not after they are locked out.

What to Do Next

Once the shared database is live, set up people and backups. Moving EDGEBIC from one planner to a shared server covers the six habits a shared plan needs, and how to back up the EDGEBIC database covers the SQL Server side. If you later need to point the same provider at a different database, how to change the database connection in EDGEBIC is the narrower task, and the EDGEBIC product page shows where the shared database fits in the platform.