ERROR database disk image is malformed

[Peter-Pascal]

Hallo,

ich bekomme eine Fehlermeldung: ERROR database disk image is malformed

Vermutlich ist nur eine Tabelle betroffen. Mit dem FireDac Explorer kann ich mir die Tabellen anschauen, aber bei einer Tabelle wirft der FireDac Explorer diesen Fehler aus.

Weiß jemand was das heißt? Und gibt es eine Lösung außer Backup?

Es ist nur eine Übungs-Datenbank, also nicht das ganz große Problem, aber wenn die DB mal andere nutzen, sehe ich bei diesem Problem ganz alt aus.

Danke schon mal

Gruß Peter

[himitsu]

database disk image is malformed :zwinker:

https://sqliteviewer.com/blog/databa...age-malformed/



Und wie bei allem Anderem auch, können regelmäßige Backups nie schaden.
Die DB-Dateien direkt binär kopieren, oder z.B. als SQL-Export (viele INSERTs und eventuell inkl. der CREATE TABLE)

[jobo]

Du gibst nicht viele Information zu den Umständen des Fehlers, der Größe der DB o.ä.
Bei sowas ist eigentlich die spannende Frage nicht so sehr, was das heißt, sondern wie es passiert ist.
Datenbankdateien in riesiger Größe, starker Zugriff, falsche Abfragen, Kopie erstellt während sie geöffnet war (es ist nicht unbedingt offensichtlich, wann sie (noch) geöffnet ist) usw.
Also wer will schon alt aussehen. Wenn Du noch parat hast, was zu dem Fehler geführt hat, dann wiederhole es, ansonsten reparier sie oder nimm eine Kopie.

[Peter-Pascal]

die Antworten hatte ich befürchtet. Backup schadet in der Tat nicht.

Wie Himitsu schreibt: viele Insert.

Ich habe viele Daten aus einer CSV eingelesen. Es gab auch ein paar Mal I/O-Fehler und das Einlesen wurde abgebrochen.
Dann habe ich es neu gestartet.

Jobo wie kann ich die DB reparieren? Gibt es ein spezielles Tool dafür? Der FireDac Explorer bricht ab und liest ab einer bestimmen anzahl nicht mehr ein. Wenn ich nur an diese Stelle ran käme.

Die HDU habe ich durch das Windows-Tool überprüft - kein Fehler.

Gibt es eine Möglichkeit, beim Einlesen einen eventuellen Fehler festzustellen?

Sofort wieder Lesen?


Danke für eure Antworten am späten Freitagabend.

Gruß Peter

[Peter-Pascal]

Leider kann ich nicht sagen, was zum Fehler geführt hat. Die DB ist auch nicht groß 624 KB.

Ich habe ca. 850 Datensätze aus einer CSV-Datei geladen.

Es kam dabei aber keine Fehlermeldung. Ich habe dann nicht überprüft, ob alles richtig war, das hatte ich bereits einigemal vorher schon getan und war von der Richtigkeit überzeugt.

Dann habe ich Programm und PC geschlossen und erst später beim Öffnen kam die Fehlermeldung. Es betrifft in der DB nur zwei Tabellen.

Offensichtlich muss beim Einlesen der CSV-Datei etwas passiert sein, denn genau diese zwei Tabellen werden befüllt, aber genau weiß ich es nicht.

Eben hatte ich ein Recovery-Programm installiert, das stürzte ab, als es die kaputten Tabellen anzeigen sollte.
Himitsu taucht das Programm auf dem Link etwas? Ich schaue es mir mal an.

[Delphi.Narium]

I/O-Fehler?

Datenträger von Quelle und Ziel (sprich Datenträger mit den zu importierenden Daten und den Datenträger mit der Datenbankdatei) auf Fehler prüfen.

I/O-Fehler deuten auf ein Problem an / in den Dateien hin. Das kann "Mist" in den Dateien sein oder aber auch ein Hardwarefehler.

[Peter-Pascal]

Hallo,
ich hoffe, dass ich in diesem Thread weiter machen kann und keinen neuen öffnen sollte, eigentlich handelt es sich um das gleiche Problem.

Ich bekomme ab und an den Fehler: [FireDAC][Phys][SQLite] ERROR: disk I/O error bei verschiedenen SQLITE Datenbanken.

Den Datenträger die Festplatte habe ich überprüft, bzw. Windows.
Wie kann ich die Datenbank überprüfen?

Die Fehlermeldung [FireDAC][Phys][SQLite] ERROR: disk I/O error taucht auf, wenn ich mit folgender Anweisung Daten von einer Datenbank in eine andere übertrage:

Delphi-Quellcode:

FDTableZiel.CopyDataSet(FDTableQuelle, [coStructure, coRestart, coAppend]);

Es sind immer die gleichen Daten. Ca. 1500 Zeilen mit 10 Feldern und einem BLOB Feld. Und die Ziel-DB ist leer.

Sonderbar ist, dass die Übertragung einmal ca. eine Sekunde dauert und dann wieder über eine Minute.
Ich kann kein Muster erkennen, dass ich den Fehler reprodizieren kann. Es sind halt immer die selben Daten nur immer in eine neue DB.

Gibt es etwas was ich überprüfen/testen kann?

Dann habe ich den Eindruck, dass bei einem frisch gebooteten System kein Disk I/O Error auftritt, als wenn das System schon einige Zeit lief. Möglicherweise ist der Eindruck subjektiv.

Vielen Dank

[dummzeuch]

Auf die Windows Datenträgerprüfung würde ich mich nicht verlassen. Selbst wenn Windows nichts findet, kann der Datenträger einen defekten Sektor haben, der in der Datei verwendete wird. Einfacher Test dafür: Die Datei kopieren.

[Peter-Pascal]

danke für die Antwort
Die Datei habe ich kopiert und lief anscheinend problemlos.

[jobo]

Ich habe noch nie mit Reparaturprogrammen für SQLite gearbeitet. Macht man ja nicht ohne Not. Ich setze das nur für Tests usw. ein. Da kann ich nichts Brauchbares liefern. Ein Hilfstool wurde schon genannt. Angeblich gibt es ja einige. Wenn die Datei selbst kopierbar ist, würden Nerds vielleicht mit dem Hexeditor dran gehen. Wenn das Problem halbwegs reproduzierbar bei einem Import auftritt, alles immer weiter annähern indem nur noch diese Tabellen überhaupt in der DB angelegt / genutzt werden, dann die Importmenge immer halbieren oder Sleeps einbauen zwischen den Inserts oder oder.
Wenn es eh Importdaten sind (und Backups existieren) würde ich mir die Mühe auch gar nicht machen, Daten aus der defekten Datei zu rekonsturieren.
Ich bleibe bei dem Punkt: Woran liegt es?

Falls SQLite wirklich ein Problem mit massiven Inserts hat, würde ich es nicht mehr anpacken. Habe ich aber noch nicht festgestellt bis jetzt.

Neulich habe ich einen Rechner aufgesetzt, der nur für ca. halbe Tage lief und dann sehr merkwürdiges Verhalten zeigte. Diagnose aus den Fehlern: SSD defekt (der gesamte Rechner war aus Neuteilen aufgebaut). Beim Einbau der Ersatz-SSD (M.2) habe ich dann festgestellt, dass die mit einer zu langen Schraube fixiert war, die vor dem Fixieren anschlug. Und das hat vermutlich das Problem verursachte, die M.2 SSD war nur lose verbunden, Temperaturschwankungen reichen dann vielleicht schon für diese Effekte.

Wie gesagt, wiederhole die Problemfunktion mit wechselnden Parametern, z.B. anderer Rechner usw. und finde heraus, woran es liegt.

Was mir noch einfällt: SQLite erlaubt das Attachen von "fremden" DB Files (Datenbanken) an eine "Haupt"- DB. GGf kommt man darüber etwas näher an die kritschen Punkte einer defekten SQLite DB. Wie gesagt, das würde ich nur untersuchen, wenn ich kein Backup habe und keine andere Wiederherstellungsmöglichkeit. (Bliebe noch die Frage, ob es an speziellen Daten liegt, aber das wäre schon sehr schräg und würde auch bei dem Test oben irgendwann auffallen- Importmenge immer halbieren)