Antwort von unserem Entwicklerteam (GitHub-Nutzer nicolettas-muggelbude):
Moin harihegen,
danke für den Vorschlag – "an mehreren Rechnern arbeiten" ist ein nachvollziehbares Bedürfnis, das haben wir uns ausführlich angeschaut.
Technisch wäre ein frei wählbarer Speicherort überschaubar umsetzbar (ähnliches Muster wie der bestehende Profilmanager). Das eigentliche Problem liegt woanders: RechnungsFee nutzt SQLite im WAL-Modus (drei zusammengehörige Dateien: .db, .db-wal, .db-shm). Für den beschriebenen Anwendungsfall – Datenbank auf einem NAS/in Nextcloud, von mehreren Rechnern genutzt – haben wir mehrere Varianten durchgespielt:
- Sync-Client (z. B. Nextcloud Desktop): Dateien werden erst lokal kopiert und dann verzögert propagiert. Öffnet man auf dem zweiten Rechner zu früh, bevor der letzte Schreibvorgang vollständig synchronisiert ist, entsteht ein inkonsistenter Zustand über die drei Dateien hinweg – klassische Ursache für eine korrupte Datenbank.
- Netzlaufwerk/WebDAV-Mount: Hier entfällt zwar die Sync-Verzögerung, dafür ist SQLite auf Netzwerk-Dateisystemen laut eigener Spezifikation grundsätzlich nicht unterstützt – WAL braucht Shared-Memory (mmap) zur Koordination, und das funktioniert über die meisten Netzwerkfreigaben nicht zuverlässig. Das Risiko ist hier eher noch größer, nicht kleiner.
- Sperrdatei/Lock-Mechanismus (zweiter Rechner erkennt "schon aktiv" und blockiert): Klingt naheliegend, hat aber selbst wieder ein Henne-Ei-Problem – die Sperre müsste atomar geprüft und gesetzt werden können, genau das ist über WebDAV/Netzwerkfreigaben nicht zuverlässig garantiert. Zwei Rechner könnten im selben kurzen Zeitfenster beide "keine Sperre da" lesen. Und selbst eine perfekte Sperre löst nur das Problem "zwei Prozesse gleichzeitig offen", nicht das grundsätzliche SQLite-auf-Netzlaufwerk-Problem darunter. Dazu kommt: ohne Verfallslogik sperrt ein Absturz die Nutzerin dauerhaft aus der eigenen Datenbank aus, mit Verfallslogik öffnet sich das ursprüngliche Zeitfenster wieder.
Jede Variante reduziert das Risiko bestenfalls, schließt es aber nicht – bei einer Buchhaltungsdatenbank ist uns das zu riskant, gerade weil RechnungsFee aktuell kein Mehrplatzsystem ist und eine beschädigte Datenbank im schlimmsten Fall Monate an Buchungen betreffen kann. Wir haben uns deshalb entschieden, das nicht umzusetzen.
Der für uns richtige Weg für "von mehreren Rechnern nutzen" ist eine geplante Docker-Version für Selbst-Hoster – die wird von Grund auf mehrplatzfähig gebaut (echter Datenbankserver statt einer über ein Netzlaufwerk geteilten SQLite-Datei). Das steht bereits als größeres Vorhaben auf unserer Roadmap, aktuell ohne festen Zeitplan.
Danke nochmal fürs Mitdenken – falls dir zur Docker-Version noch etwas einfällt, gerne dort weiter diskutieren.
Auf GitHub ansehen
Community