rouggy/OpsLog
0
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 58 Wiki Activity

chore: release v0.22.9

Browse Source
This commit is contained in:
rouggy
2026-08-02 06:40:10 +02:00
parent 296a4a55c0
commit f6cd6e999a
38 changed files with 1308 additions and 297 deletions
Download Patch File Download Diff File Expand all files Collapse all files
wiki/Profiles-and-Databases.md
+28 -10
View File
@@ -6,18 +6,29 @@ Every setting in OpsLog is **per-profile**: station identity, CAT, lookup, QSL
defaults, awards display, antennas, and which logbook to use. Create one profile
per callsign / station / event.
Switch or manage profiles in Settings. The active profile decides which logbook
your QSOs go to.
The **callsign in the top bar is the station switcher** — click it and pick a
profile. Managing profiles is at the bottom of that list (and in Settings).
## Config vs. logbook — two different stores
## Two separate databases
Since 0.21.0 the settings and the QSOs live in **separate files**:
| Store | What | Where |
|-------|------|-------|
| **Config** | settings, profiles, rigs/antennas, cluster nodes, lookup cache, award lists, QSL templates | always the **local SQLite** file under `data/` |
| **Logbook** | your QSOs | where the active profile points — local SQLite **or** shared MySQL |
| **Settings database** (`settings.db`, or `opslog.db` on older installs) | settings, profiles, rigs/antennas, cluster nodes, lookup cache, award lists, QSL templates | always the **local SQLite** file under `data/` |
| **Logbook** (`logbook.db`) | your QSOs | where the active profile points — a local SQLite file **or** shared MySQL |
Keeping config local means the UI is instant even when the logbook is a far-away
MySQL server.
Keeping the settings local means the UI is instant even when the logbook is a
far-away MySQL server. Settings → Database shows the two as separate sections,
with an *Open folder* shortcut; a logbook file can be **renamed or relocated**
(its QSOs move with it), and the status bar names the **logbook** file — that
is the one to back up.
A profile can point at its **own logbook file** — ideal for a visiting
operator, whose contacts stay out of your log without touching your settings.
**Portable**: paths inside the OpsLog folder are stored relative to it, so
moving the whole folder to another drive or PC loses nothing.
## Shared MySQL logbook (multi-operator)
@@ -25,11 +36,18 @@ Point a profile's logbook at a **MySQL** database so several operators run **one
log** — e.g. a multi-op special-event call. Configure the host / database /
credentials in the profile's database settings.
This is also what powers [[Multi-Operator Live Status]] (each instance heartbeats
its activity into a `live_status` table).
- The database and tables are converted to **utf8mb4** on connect, so Cyrillic
or Polish characters from a QRZ lookup store correctly even when the hosting
panel created the database as latin1.
- An FT8/MSHV QSO that cannot reach a laggy shared database is **parked and
re-logged automatically** once it recovers — no lost QSOs.
- Switching to a profile whose MySQL is unreachable shows a clear warning
instead of silently staying on the previous logbook.
This is also what powers [[Multi-Operator Live Status]].
## Backups
Optional **database + ADIF backup at shutdown** (Settings → Backup). Regardless,
copying the `data/` folder backs up your config and local logbook. See
copying the `data/` folder backs up your settings and local logbook. See
[[Settings and Data]].