Reading EDGEBIC Run Logs and Run History

EDGEBIC keeps several distinct run logs, and reading them well means knowing which surface owns which event: import runs write one file per run, scheduled integrations keep a browsable run history, startup errors write to a dedicated file, and security events accumulate in an append-only audit trail inside the database. In EDGEBIC by User Solutions a log is not a single wall of text to grep. It is a set of purpose-built records, each opened from the place that produced it, so a question about what happened has a specific answer rather than a search.

This post is the administrator's map of those surfaces. For the full reference behind every control mentioned here, read the EDGEBIC admin guide. This piece names controls that live in the Integration tab, the import result dialog, and the recovery window, never any internal path.

Import Run Logs: One File Per Run

Every import you run, whether from a file or through the data-import workflow, produces a result dialog when it finishes. That dialog shows the tally (how many records were created, updated, reused, or failed) and it opens the run's own log file directly. Import runs write one file per run, so you are always reading the outcome of exactly the run you just executed.

The value of the file over the tally is specificity. A summary that says twelve rows failed is a headline. The log turns it into twelve named rows, each with the reason it failed, so you can correct the source spreadsheet and re-import instead of guessing. This is the difference between knowing something went wrong and knowing what to fix.

If you run imports regularly, treat the log as the second half of every import, not an optional extra. The tally tells you whether to celebrate; the log tells you what to do next.

Integration Run History: The Persistent Record

Scheduled and file-watched syncs run without anyone watching, so they need more than a momentary dialog. The Integration tab keeps a persistent run history: a list of every run with its status, timing, and row counts, plus a detail view that reads the tail of that run's log.

Two design choices make this history trustworthy. First, a run row is written before any work begins and finalized only when the run ends, so a run is always visible even if it fails partway. Second, a run that was still marked Running when the application restarted is flipped to Interrupted by the startup sweep, so a crash leaves a detectable orphan rather than a silent gap. When you scan the history and see a clean sequence of Completed rows, that is real evidence the syncs are healthy. When you see an Interrupted row, you know exactly which run to investigate.

The run history also outlives the integration that produced it. Deleting an integration definition does not erase its past runs, because the audit value of the history is separate from the definition. An admin reviewing what happened last quarter can still see it even if the integration itself was retired.

Startup Errors: The Recovery Log

When EDGEBIC cannot open its database at launch, it does not crash. It opens a recovery window that shows the error with expandable details, embeds a data-source editor so you can fix the connection on the spot, and offers to retry, reset to the default local database, repair the database, or exit. That same failure is written to a dedicated startup log.

This log is the one support asks for when the application will not start, because it captures the condition before the main application ever loads. A shared server that was down for maintenance, a data source pointed at the wrong place, or a permissions change on the database file all land here. Pair the log with a note of what changed recently and the diagnosis is usually quick. For a broader view of connection problems, the database connection troubleshooting guide walks the same recovery window in detail.

The Security Audit Trail

Security-relevant events (sign-ins, account and permission changes) accumulate in an append-only audit trail inside the database. It is not a run log you open from a dialog. It is a permanent record your administrator or support queries when a compliance question arrives.

Two things keep that record meaningful. There is no in-app screen to browse it yet, so treat it as a queryable record rather than a dashboard. And its value depends on account hygiene: one account per person, never a shared login, so that every entry names a real individual. That is exactly why role-based access insists on individual accounts. A shared "planner" login turns the audit trail into a record that cannot answer the question it exists to answer.

Which Log for Which Question

The skill is matching the question to the surface. This table is the shortcut.

The last row points at the schedule change record, which logs every accepted schedule change so a plan's history is traceable. It is the audit surface planners care about most, and it is covered in the EDGEBIC schedule change log.

A Reading Habit Worth Keeping

None of this is heavy. Read the import log after every import that reports failures. Glance at the integration run history when a scheduled sync matters, looking for Interrupted rows and low counts. Keep the startup log in mind as the thing support wants when the application will not open. And keep accounts one-per-person so the audit trail stays worth querying.

A team that reads its logs by habit catches a broken sync the morning after rather than the week after, and hands support a specific file instead of a vague symptom. One further surface sits behind these when a scheduling run itself is the mystery: the EDGEBIC scheduling session log is the decision-by-decision trace to reach for once the failure dialog and the anomaly report have not explained what happened. For the wider operational picture behind these surfaces, see what production scheduling is, and for the full administrator reference, return to the EDGEBIC admin guide.