EDGEBIC Deployment Options Explained: One Laptop or the Whole Plant

Manufacturing software deployment options usually arrive as a project: provision a server, size a database, schedule a rollout weekend. EDGEBIC by User Solutions is built so the first deployment is none of that. First launch creates a single-file local database automatically, with nothing to install and nothing to configure, and the same application later points at a shared SQL Server database for a whole planning team by changing one setting and restarting. This post covers both, plus what actually changes between them.

The click-level install steps are in how to install and connect EDGEBIC, and the growth path in detail is in moving from single user to shared server.

The Two Real Options

The bottom two rows exist for honesty rather than choice. If someone selects a not-yet-available provider, the application blocks the switch with a message. The in-memory option is genuinely useful for a throwaway demo where you want a clean slate every time, and genuinely dangerous if anyone mistakes it for storage.

So the decision is binary: local file, or shared SQL Server.

Option One: The Single-File Local Database

This is the default and it is not a trial mode. Every feature works against it: finite capacity scheduling, the optimizer, the Gantt, quoting, actuals from the shop floor kiosk, reports.

What "no setup" means precisely: on the first launch of a new installation, the application creates the database file and builds its full schema from scratch. On a brand-new machine that takes a few extra seconds, which is the one-time cost of the tables being created. There is no database software to install, no service to start, no port to open, and nothing for IT to approve.

Two properties make it pleasant to live with:

It is one file. Copy it to move a whole system, including users, master data, routings, and schedules. Close the application first. The Export button produces a timestamped backup next to the database, safe even while the application is running, and restoring is copying the file back.

It is portable but single-workstation. One person at a time, on one PC. That is the honest boundary, and it is the reason the shared option exists.

Who it suits: a single planner, an evaluation, a second machine used for what-if work, a plant that runs one schedule from one desk. Plenty of small manufacturers fit that description permanently, and the NIST Manufacturing Extension Partnership network spends much of its time with shops in exactly that position.

Option Two: A Shared SQL Server Database

When a second planner appears, you point every installation at one SQL Server database. Each person still runs the EDGEBIC application on their own Windows PC. There is no browser client and no separate application server to stand up: the shared piece is the database, and only the database.

What IT needs to provide: a server name, and either Windows-authentication rights or a SQL login. The database itself does not need to exist first, because EDGEBIC creates it on the first connection and builds the schema automatically.

What you get: every planner sees the same live plan. A schedule run by one person is visible to the others. Actuals logged at a kiosk land in the same place the planner reads. Users live inside the database, so accounts and roles are shared too.

One honesty note that belongs in the evaluation and not in a surprise six months later: the current version is last-write-wins. If two people edit the same record at the same moment, the second save silently overwrites the first. Scheduling runs are not the problem; simultaneous edits to one master data record are. Most teams remove the issue by dividing work naturally, one planner per area or product family, so two people rarely have the same record open.

What the Two Options Do Not Change

It is worth being explicit about what stays identical, because the usual assumption is that the "small" deployment is a cut-down one.

The application on the desktop is the same build in both cases. The provider is a setting.

System Requirements, Per PC

Nothing on that list is unusual for a shop floor office PC. The administrator rights requirement applies to the installer writing to Program Files, not to running the application day to day.

The Kiosk and Other Machines on the Same Database

One question shapes the deployment more than the planner count: does the shop floor log its own actuals?

The shop floor kiosk is a simplified punch-in and punch-out terminal for operators, launched from the main application's toolbar. It reads scheduled operations and writes actual hours back. That means the kiosk and the planner are reading and writing the same database, and a kiosk on a different PC to the planner is a second user by definition.

So the honest rule is: one PC total means the local file; anything that adds a second machine means the shared database. A single planner with a kiosk terminal on the floor is a two-machine deployment even though it is a one-person plant.

That is not an argument against starting local. It is an argument for knowing which trigger will move you, so the move is planned rather than discovered. Actuals capture is covered in the EDGEBIC shop floor guide.

Why the Local File Is Not a Dead End

Single-file databases carry a reputation for being toy storage, and it is worth separating that reputation from what actually constrains this one.

It is not a feature subset: the scheduling engine, the optimizer, quoting, reports, and the Gantt all behave identically. It is not a data ceiling in any shape a job shop reaches. What it is, precisely, is single-workstation: one application, one PC, one person at a time.

Two properties follow from that, and both are advantages until the day you outgrow them. Backups are a file copy rather than a database job. And the whole system is portable: close the application, copy one file, and a complete plant configuration moves to another machine, users and schedules included.

The move to a shared database, when it comes, is a settings change plus a restart on the same install. There is no different product, no different license model, and no reinstall.

Choosing, in Three Questions

How many people need to change the plan? One means the local file. Two or more means SQL Server. People who only need to read a schedule still need their own installation and account, so count readers too.

Does IT already run SQL Server? If yes, adding one more database is a familiar request and the shared option costs almost nothing. If no, and you have one planner, the local file needs nothing from IT at all.

Where must the data live? EDGEBIC keeps production data inside your network in both options. If that is a hard requirement in your industry, this deployment model answers it without a compliance conversation. For the wider trade-off, see cloud vs on-premise scheduling.

The Path Between Them Is Short, With One Caveat

Moving from the local file to SQL Server is a provider change in the Settings screen followed by a restart. It is not a reinstall and not a different product.

The caveat is data. Switching providers does not move your data. The old database keeps everything and the new one starts empty. Plan the data step deliberately: take an export first, then either migrate or rebuild master data from your standard import files. Shops that loaded products, work centers, and routings through import masks find this step small, because the source files are already shaped correctly and reloading is running imports rather than retyping. Shops that typed everything by hand should treat it as a real task.

The full sequence, including what carries over and what does not, is in moving from single user to shared server.

What Goes Wrong, Briefly

Three deployment problems account for most support calls, and all three have a documented recovery:

• The database is unreachable at startup (a stopped server, a moved file). A recovery window opens instead of the main application, with the connection editor embedded so you can fix it on the spot.
• A copied configuration cannot decrypt its saved SQL password, because that password is tied to the Windows account that entered it. The person re-enters it under their own identity, or you use Windows authentication and avoid the situation.
• "All my data is gone" after a provider switch. It is not: the old database is untouched and you can switch back from the same screen.

Each of these is covered with the fix in deployment and database mistakes in EDGEBIC.

Where to Go Next

Read how to install and connect EDGEBIC for the first-run wizard and the connection fields, and moving from single user to shared server for the growth path. Planning EDGEBIC hardware and sizing covers what each of these options actually needs, from one Windows workstation to a shared SQL Server on an IT-managed machine. Access control, which becomes real the moment a second person signs in, is covered in EDGEBIC users and roles explained. The full administrator's journey is in the EDGEBIC admin guide.

Tell us how many planners you have today and how many you expect next year, and we will size the deployment on a demo call for EDGEBIC.