SQLite or SQL Server: EDGEBIC Database Options for IT Buyers

EDGEBIC runs on two databases: a local SQLite file for a single workstation and Microsoft SQL Server for a shared, multi-user plant, both fully supported and verified by the same tests, so you can start small in minutes and scale to a shared server without changing how the software behaves. EDGEBIC by User Solutions is a desktop application that keeps your scheduling data on your own infrastructure. For an IT buyer, that combination of a zero-friction start and a clear enterprise path, with no cloud requirement in between, is often the deciding factor. This post lays out the choice.

The Two Production Databases

EDGEBIC supports two databases for real use. Both are fully implemented and both are exercised by the same automated test suite, so neither is a second-class citizen.

SQLite is the default. It is a single database file that lives on the workstation, with no server to install and no database administrator required. A planner can install EDGEBIC and be scheduling within minutes. This is the right choice for a single-seat deployment, a pilot, or any situation where one person owns the schedule.

SQL Server is the shared, multi-user option. It runs on your own server on your own network, and every user connects to the same database. This is what you deploy when several planners, supervisors, and shop-floor stations all need to work against one authoritative schedule at the same time.

A third internal option exists for testing only and holds nothing on disk, which is why it never appears in a production plan.

When to Choose Each

The decision is about how many people touch the schedule, not about how big your shop is.

The pattern most shops follow is to begin on SQLite for immediate productivity, then move to SQL Server when a second and third person need concurrent access. Starting on SQLite costs nothing and teaches your team the product. The move later is deliberate, not forced.

No Cloud Required, Data Under Your Control

EDGEBIC is an on-premise application. Your scheduling data lives in your database, on your equipment, governed by your policies. There is no requirement to route production data through an external service. For manufacturers with defense, aerospace, medical, or contractual data-handling obligations, this is frequently the point that clears the software for use at all. The heritage behind EDGEBIC is instructive here: User Solutions, founded in 1991, has delivered scheduling to organizations including the US Navy, GE, BAE Systems, and Cummins, environments where data control is not negotiable.

When SQL authentication is used, EDGEBIC encrypts the stored password on disk and ties that encryption to the Windows account of the person who entered it. Copy the configuration file to a different user and the password cannot be decrypted, by design. Better still, Windows Authentication is fully supported, which means you can connect to SQL Server with no stored password at all, using the same domain identities your IT team already manages.

Moving From SQLite to SQL Server

The switch is a settings change, and EDGEBIC does the database work for you on the next launch.

1. In Settings, select SQL Server as the provider.
2. Enter the server name and the database name you want.
3. Choose Windows Authentication or SQL Authentication, and enter credentials only if you chose SQL Authentication.
4. Test the connection. If the target database does not exist yet, EDGEBIC tells you plainly that the server is reachable, the sign-in succeeded, and the database will be created on first launch.
5. Apply and restart. On the next boot, EDGEBIC creates the database and builds its full schema automatically.

One honest note: the switch changes where the software writes, but it does not carry your existing SQLite data across for you. Transferring the data you have already entered is a separate export-and-import step. For a shop moving from a pilot to production, that is usually a planned event, not an obstacle.

The important guarantee is that the application behaves identically on either engine. Everything your planners have learned, every routing you have built, every report you rely on, works the same way after the move. That sameness is not an accident. It is verified by the test suite that runs against both databases.

A Worked Example: A Plant Grows From One to Fifteen Users

Consider a plant that installs EDGEBIC for a single planner.

On day one, there is no configuration file, so EDGEBIC creates a local SQLite database automatically and opens a guided first-time setup that walks from data source to shift to product to work center to routing to first order. Within an afternoon, the planner is producing real schedules. No server, no database administrator, no IT ticket.

Six months later, the plant has grown, and now fifteen people need to see and act on the same schedule: three planners, several supervisors, and shop-floor stations. IT stands up a SQL Server instance and, in EDGEBIC's settings, points the software at it with Windows Authentication. On the next launch, EDGEBIC creates the production database and its schema. The team's existing data is transferred with an export and import, and all fifteen users now work against one shared plan.

Nothing about how a schedule is built changed. The engine that produced the single planner's schedule is the same engine now serving fifteen people. Only the storage moved, from a file on one desk to a server on the network.

What IT Actually Has to Manage

For the SQLite deployment, the answer is close to nothing. The database is a file. Backing it up is copying that file, and EDGEBIC can export a consistent copy even while the application is running. Restoring is putting the file back.

For SQL Server, EDGEBIC fits into your existing database operations rather than replacing them. Your standard backup, security, and access policies apply to the EDGEBIC database like any other. EDGEBIC also offers an export for the SQL Server database, and where the standard export tool is not on the machine, it hands you the exact command to run so you are never stuck.

Connections are tuned for the real world. The connection timeout is set short so the test-connection button fails fast when a server is unreachable, instead of freezing while you wait. And the software forces on the SQL Server setting that lets its data-access patterns run correctly, so you do not have to know to configure it.

The Bottom Line for a Buyer

The database choice in EDGEBIC is not a fork in the road you can get wrong. It is a progression:

• Start on SQLite for a single seat, with no server and no administration, and be productive the same day.
• Move to SQL Server when multiple people need one shared, authoritative schedule, using your own infrastructure and your own identities.
• Keep your data on premises throughout, with no cloud dependency and encrypted credentials where a password is used.
• Lose nothing in the move, because the application behaves identically on both engines and that sameness is tested.

For a shop weighing scheduling software, this removes a common source of risk. You are not committing to an architecture you might outgrow, and you are not handing your production data to an outside service. You start where you are and grow on your own terms. If you are consolidating from an older User Solutions product, the same principle applies to your upgrade path, which you can read about on the move from RMDB to EDGEBIC.