Keeping the EDGEBIC Database Healthy Over Time

Keep the EDGEBIC database healthy over time with three habits: back it up on a schedule and before anything destructive, clear data only through the guarded utility, and know the startup recovery path. In EDGEBIC by User Solutions the local database is a single portable file backed up with one click, and a shared SQL Server database joins IT's standard rotation, so durability is a matter of habit rather than heroics. This post covers the maintenance that keeps a scheduling database dependable for years.

Database housekeeping is one chapter of the administrator's job. For the full reference, read the EDGEBIC admin guide, and for the day-one setup, see choosing a database for EDGEBIC. This post is the ongoing care. It names controls that live in Settings and the data-management utilities, never any internal path.

The Backup Habit Comes First

Every other maintenance task rests on backups, because a backup is the undo that destructive operations do not otherwise have. The habit has two halves.

On a schedule. For the default local single-file database, the Export control on the DataSource tab creates a timestamped backup next to the database file with one click, safe even while the application is running; restoring is copying the file back with the application closed. For a shared SQL Server database, put the scheduling database in IT's standard backup rotation so a nightly copy exists whether or not anyone remembers to make one. Backups on a schedule, not on memory, is the rule.

Before anything destructive. The documented rule of thumb is to export before every data clear, mass routing re-import, or database provider switch. Those three operations are the ones without a built-in undo, so a one-click export first is what turns a mistake into a restore. It costs one click, and it is the cheapest insurance in the whole application.

The reason to internalize this now, while everything is fine, is that the moment you need a backup is the moment it is too late to make one. A database that has been exported before every risky operation for two years is a database that has never lost a bad afternoon's work.

Clear Data Only Through the Guarded Utility

Over a database's life you will legitimately want to wipe data: resetting a training database, clearing a demo, or starting a fresh planning year. The Clear Data Tables utility exists for exactly that, and it is deliberately hard to trigger by accident because the operation has no undo.

The guards are worth knowing before you need them. A red warning banner marks the screen. You choose between clearing selected areas (each expandable to show what it cascades to, so you see the downstream effect before committing) and a full database wipe. A separate opt-in is required before user accounts are touched, so clearing jobs does not accidentally clear your team. And a typed confirmation word is required before the button enables, so the last action is deliberate rather than reflexive.

Use the selected-areas mode for the common case, like starting a planning year: clear jobs and schedules while leaving work centers, products, and customers in place. Read each area's cascade before you commit, because clearing one thing can cascade to related records. And take the export backup first, always, because the guards prevent an accident but only the backup reverses a decision.

Keep the Logs and Layouts Tidy

Two lighter housekeeping items keep the system pleasant to run.

Logs. Different activities log to different places, and knowing where each lives saves time when something looks wrong. Import runs log one file per run, opened directly from the import result dialog. Startup errors log to a dedicated file. Scheduling diagnostics write to a support-driven folder. Security events live in the database's audit trail. When something looks off operationally, the troubleshooting guide is the place to start; when it looks administrative, the relevant log is. A glance at the logs for repeated errors is a fair periodic health check.

Layouts. Grid and panel layouts save per user automatically, and they can drift as people rearrange columns. Reset them per view from that view's configuration dialog, or wholesale through data management. This is cosmetic rather than structural, but a clean layout is one less thing a returning user has to fix.

The security audit trail deserves a note here too. It is an append-only record inside the database, so it accumulates a permanent history of security-relevant events. There is no in-app screen to browse it yet; it exists as a record your administrator or support queries when a compliance question arrives. Healthy database maintenance means knowing that record is there and keeping accounts one-per-person so it stays meaningful, as role-based access intends.

Know the Recovery Path Before You Need It

A healthy database also means a recoverable one. If EDGEBIC cannot start against its database, you get a recovery window instead of a crash. It shows the error with expandable details, embeds a data-source editor so you can fix the connection on the spot, and offers four actions: retry the same connection (after restarting a stopped server, for instance), reset to the default local database, repair the database (which rebuilds internal version bookkeeping for a database whose structure is already current, without changing data), and exit. Startup errors also land in a dedicated log for support.

Knowing this path exists changes how a failure feels. A shared server that was down for maintenance is a retry once it is back, not a reinstall. A connection that got misconfigured is a fix in the embedded editor. The recovery window turns a startup failure from an emergency into a short, guided fix.

A Worked Maintenance Rhythm

Put the habits into a rhythm and the database mostly takes care of itself.

None of it is heavy. It is a scheduled backup, a one-click export before the few operations that lack an undo, a guarded utility used deliberately, and a recovery path you have read once. That is what keeps a scheduling database dependable across years and across a growing team. For the full administrator reference behind every control here, read the EDGEBIC admin guide, and for the deeper backup mechanics, see how to back up the EDGEBIC database.