Design flaw: opslog.db held BOTH the config (settings + profiles) AND the SQLite
logbook, so the only way to a separate SQLite logbook — the whole-app "change
database location" pointer — swapped the config too, wiping the operator's setup
(reported: creating a new SQLite for a visiting op lost all profiles/settings).
Now the two are separate files:
- Settings database: settings + profiles. Fresh installs name it settings.db;
existing installs keep opslog.db.
- Logbook (QSOs): a dedicated logbook.db next to the settings db, or a
per-profile file (profile.ProfileDB.Path), or MySQL. connectLogbook opens the
logbook file (db.Open creates+migrates on first use); the settings db is used
as the logbook only if the split ever fails.
One-time, non-destructive migration at startup: if there's no logbook file yet
but the settings db already holds QSOs (legacy combined opslog.db), seed
logbook.db with a clean copy via VACUUM INTO — contacts move to the logbook, the
originals stay in the settings db as an untouched backup.
UI: the Database panel now shows the settings database and this profile's logbook
as two clearly labelled sections (+ "Open folder"), and the logbook selector is
SQLite (default logbook.db, or a dedicated file via "Choose a dedicated file…")
vs MySQL — no more confusing shared/separate choice. New binding RevealDataFolder.
rouggy
2b3d118d84