Saving your work¶

ProcessDB keeps every edit on your computer until you decide to publish it. Nothing you draw, type, or fit reaches the database until you commit.

That is what makes it safe to experiment: you can restructure a model, try three rate laws, and reload if you do not like any of it. It does mean that the Save button matters, and that the answer to "did I save that?" is always in the same place.

Committing¶

File → Commit, or the Save button in the toolbar. The button is greyed out when you have nothing to save — which makes it the quickest way to check whether you have unsaved work.

ProcessDB writes your changes in a careful order — parent objects before the things that depend on them, and the data you cannot recreate before the cosmetic data you can.

When a save fails¶

If any part of a save does not go through, ProcessDB shows a Save Report naming exactly which kinds of object did not persist, and why.

Unsaved items stay marked as unsaved. Address whatever the report names — a value that will not fit a field, a required entry left blank, a lost network connection — and press Save again; only the outstanding items are re-sent.

For a transient network failure, ProcessDB retries a few times on its own before asking whether to keep trying.

When a save cannot be made to succeed, File → Export Unsaved Changes… writes everything outstanding to a local file that support can use to recover the work. It is the escape hatch, not the normal path.

Reloading¶

File → Reload discards everything uncommitted and re-reads the database. ProcessDB warns you first if you have unsaved changes.

It is the way to start over, and the way to pick up something a colleague has committed since you loaded.

Quitting¶

Quitting with unsaved changes asks first, and offers to save. If you quit without saving, the journal (below) keeps a copy, and ProcessDB offers it back the next time it starts.

Crash recovery¶

ProcessDB continuously writes a local journal of everything you have changed but not committed — a few seconds after each edit, before and after each save attempt, and at shutdown.

If ProcessDB or your computer stops unexpectedly, the next launch notices the journal and offers to restore that work instead of loading fresh data from the database. Accept and you are back where you were, with the same changes still uncommitted.

The journal is per computer login. Declining the offer archives it rather than deleting it, so nothing is lost if you change your mind.

The Parameter Explorer saves separately¶

The Parameter Explorer has its own Save button, and it is not covered by the main window's Commit.

It saves:

• parameter values you edited in its table;
• your graph layout for that MOE.

If you quit with parameter edits still in a Parameter Explorer, ProcessDB warns you that they are not included in "Save and Quit" — save them from that window first.

The practical rule: when you have been fitting, press Save in the Parameter Explorer, then Commit in the main window.

What is saved where¶

Regenerating equations changes nothing that needs saving: the listing is derived from things that are already saved, and is rebuilt on demand.