@spassig
Mal etwas Grundlegendes zu sqlite: Wenn du Daten änderst, lässt das DB-System zunächst die eigentliche Datenbank unangetastet und schreibt die Änderungen in die Journal-Datei. Erst wenn der Befehl commit() ausgeführt wird, wird das Journal in die Datenbank eingepflegt und anschliessend gelöscht. Vermutlich setzt C1 diesen Befehl erst beim Beenden des Programms. Daraus ergeben sich zwei Möglichkeiten:
-C1 ist vor dem commit abgeschmiert. Dann könnte das Journal korrupt sein, damit wären die Daten der letzten Sitzung hin.
- Du hast C1 während des commit abgeschossen. In diesem (seltenen) Fall wäre der Katalog wahrscheinlich komplett im Eimer.
Ein erstes Indiz für die Situation könnte das Änderungsdatum der Dateien liefern. Ist die db jünger als das Journal, sieht es schlecht aus. Ansonsten empfiehlt sich folgendes Vorgehen:
Erst mal Sicherungskopie von Journal und db machen, dann das Journal löschen. Das writelock muss natürlich auch weg. Dann sollte die Datenbank mit dem Zustand vor der letzten Sitzung verfügbar sein.
Sqlite ist kein besonders leistungsfähiges Datenbanksystem. Verwaltest du damit grössere Bestände, setzt du den Zweitakter einer Motorsäge als Antrieb für einen Bus ein. Da kannst du als Anwender keine spontanen Reaktionen erwarten und solltest dir Gedanken um Überlast-Situationen machen. Eine mögliche Strategie: C1 öfter herunterfahren und neu starten, damit das Journal nicht zu gross wird.
@rodinal
Danke für das sehr informative feedback.
Habe mal zwei screenshots angehängt.
Der erste zeigt die 4 Kataloge auf der HD.
Bis auf den korrupten lassen sich alle zwei anderen öffnen.
(Den korrupten Katalog habe ich noch als Duplikat erstellt)
Der zweite screenshot zeigt den Inhalt des korrupten Katalogs.
Deine Infos bzgl. Datum checke ich später.
Jochen
Anhänge
-
Exif-DatenBildschirmfoto 2016-11-15 um 09.00.29.png191,9 KB · Aufrufe: 6
-
Exif-DatenBildschirmfoto 2016-11-15 um 09.09.16.png335,4 KB · Aufrufe: 7