Hallo,

erstmal zum Problem, das ich lösen möchte. Es scheint ein Konto der Volksbank irgendwann gelöscht worden zu sein, was mich sehr wundert. Nach dem erneuten Testen der Bank-Konfiguration und automatischem Hinzufügen von Konten, ist das Konto wieder da, konnte aber nur die letzten paar Monate abrufen.
Jetzt würde ich gerne in meinen regelmäßigen Backups herausfinden, wann das Konto verschwunden war, und womöglich ein älteres Backup von diesem Konto wieder einspielen.
Wie kann ich die Datenbank von Hibiscus mit einem SQL-Editor öffnen und das prüfen?

Wenn ich das Backup gefunden habe, wo das Konto noch existierte müsste ich wahrscheinlich dieses Backup mit Hibiscus öffnen, das Konto exportieren, und mit dem aktuellen Datenstand dann nochmal importieren?

Kann es sein, dass du vielleicht einen Bankzugang löschen wolltest, dabei aber versehentlich das Konto gelöscht hast?



Du kannst mit einem JDBC-Tool wie ExecuteQuery oder DBeaver auf die Datenbank zugreifen. Die Zugangsdaten werden dir im Menü unter "Hibiscus->Über->Datenbank-Informationen" angezeigt.



Exportiere nicht das Konto sondern die darin enthaltenen Umsätze. Das Konto allein zu exportieren/importieren bringt nicht viel.

Das manuelle Suchen in den Datenbanken ist ein mühsamer Vorgang. Ich würde dir empfehlen, eine zweite Hibiscus-Installation mit einem abweichenden Benutzerordner einzurichten (siehe https://www.willuhn.de/wiki/do…nis_nutzen) und dort dann die von Jameica automatisch erzeugten Backups unter "Datei->Backups verwalten..." importieren, bis du eines gefunden hast, in dem das Konto noch existierte.

2. Hibiscus Instanz auf die unterschiedlichen Backups ansetzen ist wahrscheinlich am sinnvollsten.

Da ich aber eh mal in die Datenbank schauen wollte, um auch evtl. global einige Tags in den Kommentaren umbenennen zu können, habe ich DBeaver installiert und die Datenbank mal als H2 embedded verbunden. Die Verbindung scheint zu funktionieren, die ganzen Tables und Views sind aber leer.

Ich dachte nun, ich switche mal mit jameica -f durch die btrfs snapshots...
de.willuhn.jameica.system.JameicaException: java.io.IOException: Read-only file system
Da hat er recht, aber muss das wirklich rw sein, wenn ich da nur mal reinschauen möchte? Wäre es nicht sinnvoll, auch den read-only Zugriff für soetwas zu erlauben mit der Anmerkung (read-only) im Fenstertitel?

DBeaver ist primär ein Tool zum Ausführen von SQL-Kommandos. Den Inhalt der Tabellen zeigt man sich daher typischweise an bzw. bearbeitet ihn, indem man SQL-Kommandos wie SELECT, UPDATE, INSERT, DELETE ausführt. Hierzu müsstest du dich ggf. mit SQL beschäftigen.

Wenn du im Navigator-Fenster mit der rechten Maustaste aber auf eine Tabelle klickst und dort "Edit Data" statt "Edit Table" wird ggf. auf deutsch angezeigt) waehlst, dann wird dir auch der Inhalt der Tabellen angezeigt. Andernfalls nur die Struktur der Tabelle, nicht jedoch der Inhalt.

Ja, Jameica geht davon aus, dass es Schreibrechte im gewählten Benutzerodner hat. Das kann man auch nicht zentral abstellen. Es finden sich viele Stellen im Programm, die von Schreibrechten ausgehen und ein Read-Only-Filesystem nicht berücksichtigen. Du könntest Jameica mit dem zusätzlichen Startparameter "-l" (kleines L) starten. Dann versucht das Programm zumindest nicht, die Lock-Datei zu erstellen und die Anwendung sollte grundsätzlich starten. In der jameica.log wird es aber sicher dennoch viele Fehlermeldungen geben, weil an den unterschiedlichsten Stellen versucht wird, zu schreiben. Eventuell lässt sich die H2-Datenbank auch gar nicht readonly öffnen - das habe ich nie getestet.

Nach dem Connect hab ich eine DB mit Namen H2 - XTEA, dort unter PUBLIC/Tables->View Tables gibt es keine Tabellen.

Stimmt, damit ließ es sich zumindest starten und die Umsätze anschauen. Jetzt machen meine täglichen Snapshots Sinn und ich schaue mit der parallelen Hibiscus-Instanz die Snapshots durch, bis ich meine verlorenen Umsätze wieder habe. ich hoffe, der Export aus einem read-only wird auch funktionieren.

Nebenbei erwäge ich, die Backup-Archive von Jameica evtl. abzuschalten. Das ist irgendwie doppelt, wenn mein $HOME sowieso tägliche snapshots hat.

Das kann ich nicht reproduzieren. Bei mir werden die Tabellen angezeigt. Wichtig ist, dass bei "Database/Schema" der komplette Pfad angegeben ist - incl. der Parameter. Also z.Bsp.:

/home/<user>/.jameica/hibiscus/hibiscus/h2db/hibiscus;CIPHER=XTEA

Ggf. muss noch der passende H2-Treiber ausgewählt werden. Hierzu auf "Edit Driver Settings" klicken und dort bei "Libraries" auf "Add File" klicken und die Datei "h2-1.4.199.jar" aus dem Ordner "lib/h2" im Programmordner von Jameica auswaehlen und den vorherigen Treiber entfernen. So ist sichergestellt, dass die selbe Treiberversion verwendet wird, die auch Jameica nutzt. Beim Passwort ist wichtig, dass es genauso eingegeben wird, wie es im "Über"-Dialog von Hibiscus angezeigt wird.

Da steht bei mir:
jdbc:h2:/home/mb/.jameica/hibiscus/h2db/hibiscus;CIPHER=XTEA

Die Datei gibt es nicht, ein findet nichts. Die aktuelle Library ist aber bereits com.h2database:h2:RELEASE/h2-1.4.199.jar. DBeaver ist 6.0.5, also aktuell.

Die Datei "h2-....jar" liegt nicht im Benutzerodner von Jameica sondern im Programmordner.
Die Treiberversion stimmt aber. Warum dann bei dir die Tabellen nicht angezeigt werden, kann ich mir aber leider auch nicht erklären.

Das parallele Arbeiten mit 2 Hibiscus Instanzen und -l zum ignorieren des Locks ist sehr Praktisch. Hast du eine Idee, wie sich das beim gleichzeitigen Zugriff auf dasselbe Directory verhält? Wenn man z.B. selbst darauf achtet, nur mit einer Instanz Änderungen zu machen, die andere rein lesend zu betreiben?
Zur Not könnte ich natürlich mit der 2. Instanz immer auf dem Snapshot von gestern arbeiten.

Davon würde ich dringend abraten. Das Lock-File ist ja eigentlich gerade dafuer gedacht, dass eben sichergestellt ist, dass nicht zwei Instanzen parallel auf den Daten arbeiten. Den Parameter "-l" zum Ignorieren des Lock-File gibt es nur, weil manche User den Jameica-Benutzerordner auf Netzlaufwerken verwenden, die kein File-Locking unterstützen. Aber auch da muss sichergestellt sein, dass nicht zwei Instanzen parallel genutzt werden.

Hibiscus ist multi-threaded. Selbst wenn du nicht beide Anwendungen parallel bedienst, werden im Hintergrund Schreibzugriffe stattfinden, die zu Konflikten und Datei-Inkonsistenzen führen werden.

Wenn du die Daten wirklich parallel nutzen willst, empfehle ich dir die Nutzung einer gemeinsamen MySQL-Datenbank. Siehe https://www.willuhn.de/wiki/doku.php?id=support:mysql

Wenn es eine separate Lock-Datei ist, also nicht ein Lock auf den Dateien, dann sollte das auch auf Netzlaufwerken funktionieren. Aber ok, hab verstanden, dass das ignorieren des Locks nicht empfohlen wird.

d.h. nur der Datenbankzugriff auf die Embedded H2 ist für parallele Zugriffe nicht geeignet, wenn es mehrere Instanzen gibt? Denn ansonsten hätte man ja auch mit der externen MySQL das selbe Problem bei parallelen Instanzen?

Externe Datenbank würde sich nun schon aus mehreren Gründen empfehlen. 1. Paralleler Zugriff. Dann könnte ich mir noch das zentrale Synchronisieren über unison sparen für entfernte Installationen. Es würde aber auch bedeuten, dass ich online sein muss, um meine Daten zu erreichen. Bisher synchronisiere ich zwar mit unison gegen einen zentralen WebDAV Server, kann danach aber offline mit Hibiscus arbeiten. Mehrere MySQL Datenbanken lassen sich bestimmt auch synchronisieren, da bin ich aber nicht versiert..

Ich erinnere mich, dass du mal die Unterstützung für fremde Datenbanken neben MySQL aufgegeben hattest. Postgres habe ich schon einige, könnte das evtl. auch damit funktionieren, wenn auch ohne Support? Macht aber wahrscheinlich wenig Sinn, wenn die Unterschiede doch so groß sind.

Beides. Es ist eine separate Lock-Datei, auf der ein Lock ausgefuehrt wird. Normalerweise funktioniert das auch auf Netzlaufwerken. Scheinbar gibt es aber einige NAS-Systeme, die File-Locking nicht unterstützen. Eventuell sind es auch User, die ein WebDAV-Share per FUSE gemountet haben oder ähnliches.



Nein. Nicht nur die Datenbank. Auch alle anderen Dateien.



Der Unterschied hierbei ist, dass du zwei getrennte Benutzerordner verwenden kannst, die aber beide auf die selbe Datenbank zeigen. Damit sind die Passport- und Config-Dateien getrennt und dennoch greifen beide Instanzen auf eine gemeinsame Datenbasis zu.



Ja, den Postgres-Support habe ich aufgegeben, weil es nur von sehr wenigen Nutzern verwendet wurde. Der Code für Postgres ist zwar aus Gründen der Abwärtskompatibilität noch enthalten, ich habe aber keine Ahnung, ob er noch funktioniert, da ich ihn nicht mehr teste.