ERROR database disk image is malformed

[Peter-Pascal]

Hallo Jo,
Du hast Dir wirklich sehr viel Mühe gegeben, mir zu helfen. Vielen Dank dafür. Gerade weil es viele Vorschläge sind, komme ich der Sache näher.

Offensichtlich gibt es zwei Tabellen, die defekt sind. Es sind Master-Detail. Ich habe mir zwei Tools aus dem Internet geladen und zusätzlich noch das Delphi hauseigene Tool. Bei allen immer das gleiche Ergebnis: Es werden ca. 600 Datensätze geladen und auch angezeigt, aber dann bringen alle Tool disk image is malformed und lesen nicht mehr weiter. Offensichtlich hängt der Fehler mit dem Disk I/O Error zusammen. Mögicherweise zeigen beide Fehler einen HD defekt. Es fehlen noch ca. 200 Datensätze.

Die Daten in der DB sind nicht so wichtig, ich möchte nur verstehen und wissen, wie ich diesen Fehler vermeiden kann und was ich tun kann. Falls mal jemand anders mein Programm nutzt, möchte ich eine Lösung parat haben. Und sei es, dass ich regelmäßige Backups einbaue.

Ob es an den Daten liegt, kann ich nicht ausschließen. Es wird eine CSV Datei mit Bankumsätzen eingelesen. Starmoney hat die CSV erstellt. Interessant ist nur, das es mal klappt und mal nicht.

Beim Einlesen der CSV habe ich eine eigene Routine, die die Daten in die DB schreibt. Beim kopieren von einer DB in einer anderen DB nutze ich FDTableZiel.CopyDataSet(FDTableQuelle, [coStructure, coRestart, coAppend]); Bei beiden Vorgänge erscheint der Fehler.

Interessant ist nur, von 10 mal einlesen, geht es 2 mal schief.

Ich werd mich wohl intensiv mit Backups beschäftigen und eine Serie von Backups anlegen, auf die dann Zugegriffen werden kann.

Danke und Gruß Peter

[himitsu]

Wenn es ein Hardwaredefekt ist, dann bringt es nicht viel, wenn die Backups auch auf der selben Platte liegen,

außer diese Backups werden auch ab und an nochmal woanders hin kopiert/gesichert ... nur neue Backup-Dateien kopieren (veränderte Dateien, welche nun defekt sein könnten, in dem anderen Backup auch zu überschreiben, wäre etwas kontraproduktiv)

[Peter-Pascal]

Da hast Du Recht Himitsu,

ich hoffe auch, dass die Platte keinen Defekt hat und werde eine DB auf eine andere Platte legen und dort testen. Im PC ist noch eine SSD. Bislang hatte ich bei der SATA-Platte (glaube so hießt die) keine Fehlermeldungen bekommen.

Bin gespannt, ob da die gleichen Probleme auftauchen. Wenn es das gleiche ist, dann kann nur mein Programm das Problem sein, und es bewahrheitet sich wieder: Das Problem sitzt meistens vor der Tastatur.

[Delphi.Narium]

CSV kracht "unmotiviert" beim Einlesen in Datenbank.

Da könnte eventuell mal ein "einfaches" Öffnen mit Excel oder OpenOffice, ... helfen.

Ist die CSV "schrottig", wird das Officeprogramm auch Fehler melden oder die Daten irgendwie, aber nicht mehr der CSV-Struktur entsprechend, anzeigen.
Mit ein bisserl Glück kannst Du dann sogar erkennen, bei welcher Zeile, welchem Datensatz, etwas nicht so ganz in Ordnung ist.

So kannst Du quasi eine Gegenprobe machen, ob das Problem eher auf der Seite der Quelldaten oder eher bei SQLite liegt.

Befremdlich ist allerdings eher dashier:

Zitat:

Interessant ist nur, von 10 mal einlesen, geht es 2 mal schief.

Sowas lässt darauf schließen, dass die Hardware anfängt defekt zu werden. Sie ist noch nicht defekt genug, damit Prüfsoftware den Defekt erkennt, aber schon defekt genug, dass vereinzelt Lese- und/oder Schreibfehler auftreten.

Problem bei Hardwaretests ist halt: Die Hardware selbst hat eine Fehlerkorrektur, die versucht den Fehler zu beheben. Das kann beim Lesen und Schreiben mal mehr, mal weniger gut funktionieren.
Bei mehr wird der Fehler behoben und die Prüfsoftware merkt nix von dem/den Fehlern.
Bei weniger versucht sie es mehr oder weniger oft nochmal, so dass die Hardware noch ein paar Versuche zusätzlich bekommt, den Fehler zu beheben / vertuschen. Wenn ausreichend Versuche der Hardware die Möglichkeit geben, den Fehler zu beheben, bekommt die Prüfsoftware weiterhin nix mit.

Was aber klar auf eine derartige Situation hinweist:

Zitat:

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.

Auch das lässt auf einen "schleichenden" Defekt schließen. So quasi: Da bahnt sich was an, das erste Kratzen im Hals vor 'ner Erkältung, wobei es nicht zwingend in eine Erkältung ausarten muss.

Ein weitere Hinweis auf einen schleichenden Hardwaredefekt wäre: Mal geht das Lesen-/Schreiben problemlos schnell, mal problemlos aber arg langsam, mal garnicht.

In "grauer Vorzeit" konnte man in so einer Situation wunderbar das Neupositionieren der Schreib-/Leseköpfe der Festplatte hören. Ein wiederholtes Klicken und längere Wartezeiten beim Lesen bzw. Schreiben waren da die ersten Hinweise auf einen "zukünftigen" Hardwaredefekt.

Zitat:

Selbst wenn Windows nichts findet, kann der Datenträger einen defekten Sektor haben, der in der Datei verwendete wird.

Das ist so leider richtig und zwar weil:

Wird etwas gelesen und der entprechende Sektor ist defekt, versucht zuerst die Hardware die Daten in einen intakten Sektor zu retten. Solange das gelingt, ist das für das Betriebssystem nicht erkennbar. Erst wenn das nicht gelingt, wird das Betriebssystem entsprechend informiert.
Problem dabei: Die Hardware meint die Daten hardwareseitig richtig gerettet zu haben, dass heißt aber nicht immer zwingend, das sie auch inhaltlich (also auf binärer Ebene) korrekt gerettet wurden. Passiert zwar nur extrem selten, kann aber nicht absolut ausgeschlossen werden.
Allerdings sollte das Problem nach so einer hardwareseitigen Rettung dann behoben sein und nicht (mehr oder weniger) sporadisch erneut bei den gleichen Daten auftreten.

[Peter-Pascal]

Hallo Delphi.Narium,

Deine Erklärungen sind richtig interessant und habe ich aufmerksam gelesen.

Nach Deinen Ausführungen bin ich mir sicher, dass ein Hardware Defekt vorliegt. Was Du schreibst klingt schlüssig, zumal ich jetzt auch auf der SSD Platte eine DB angelegt habe und mit den CSV Daten gefüllt habe. Alles funkioniert ohne Probleme und in angenehmer Geschwindigkeit.

Jetzt bin ich unschlüssig, was ich mit der Platte anfangen soll, austauschen? Gibt es ein Tool das zuverlässig die Platte checken kann und defekte Sektoren markiert? Hieß es nicht Checkdsk oder so ähnlich?

Oder abwarten? Datensicherungen habe ich genug. Automatisch wird auf einer NAS gesichert und zusätzlich sichere ich noch die wichtigsten Daten auf einer externen Festplatte.

Danke für Deine umfangreichen Erläuterungen

[Delphi.Narium]

Keine Ahnung wie das bei aktuellen Windosen ist.

Kommandozeile und dann:

Code:

chkdsk c: /f /r /x /v

c: steht für den Laufwerksbuchstaben der (vermutlich) defekt(werdend)en Platte.

/v ist der "Labermodus", es werden Meldungen ausgegeben, wenn was nicht passt. Die solltest Du Dir anschauen und merken. Wichtige Meldungen sollten aber auch im Ereignisprotokoll von Windows zu finden sein. (Hast Du schonmal dort geschaut, ob es eventuell schon irgendwelche Meldungen bzgl. Hardware, Festplatte, ... dort gibt?)

Die Prüfung geht nicht unbedingt im laufenden Betrieb. Windows sollte das merken und den Befehl dann nach 'nem Neustart des Rechners als erstes ausführen. Das geschieht bevor Windows selbst richtig und vollständig geladen wird. Es läuft also quasi nur ein rudimentäres DOS und: Das kann dauern, sehr lange dauern. Ein, zwei Kaffee werden dann nicht ausreichen, ggfls. also vor Feierabend oder über Nacht oder so laufen lassen.

Was Du aber keinesfalls machen solltest: Wenn dieser Job läuft den Rechner neustarten, weil das sooooo laaange dauert. Das kann ggfls. dann das Aus für die (eventuell noch) reparierbaren Daten und Sektoren bedeuten.

Und ja, es gibt diverse Tools, die dann ggfls. auch noch helfen können, wenn Windows scheitert. Die nutze ich aber nur dann, wenn Windows scheitert. In der Mehrzahl greifen sie aber auf die gleiche API zu, die auch Windows nutzt. Also ungefähr sowas: Andere Optik für gleiche Aufgabe.

Da können wir ggfls. dann suchen gehen, wenn Du von Windows gesagt bekommst, wo denn da was hakt.

Achso: Der Hersteller hat dazu auch was zu sagen: chkdsk.
Bitte zuerst durchlesen und dann entscheiden, was für Deinen konkreten Fall am Besten geeignet erscheint. Die angegebene Lesedauer von 3 Minuten ist allerdings deutlich untertrieben

[jobo]

Einfach Dinge ausschließen, vorzugsweise grobe Entscheidungen treffen, die einfach umsetzbar sind:
Nimm irgendeinen USB Stick, pack die DB drauf und wiederhole dort den Import 10x, 100x, es ist ja offenbar nur eine kleine Datei mit einer vierstelligen Anzahl von Datensätzen.
Man kann in der Variante ohne SSD vielleicht annehmen, dass selbst ein Controller Fehler vor der SSD beim USB Stick nicht greifen würde. Ist aber auch nur geraten.
Der Zweig der fehlschlägt, wäre dann weiter zu verfolgen, aufzudröseln. Andere Disk, anderer Rechner, Importdateien halbieren, vorderere/ hintere Hälfte testen oder nach dem Split einen identischen Teil 2x hintereinander hängen, oder generierte/"genormte" Daten in großer Menge importieren.
Im Taskmanager oder besseren Tools mal nach verdächtigen Prozessen suchen (tote EXEn ..)
In der Computerverwaltung o.ä. mal die geöffneten Dateien inspizieren.
..

Datenfehler:
Dass fehlerhafte Daten zu Problemen führen (also nicht logische Probleme), kenne ich seit ca. 10-15 Jahren nicht mehr und auch da waren es schon alte, schlechte DB Treiber und der Fehler hat niemals dazu geführt, dass die DB korrupt war.

andere Fehler:
Master/Detail macht etwas hellhörig. Der Fehler ist vielleicht weniger in den Daten zu suchen, als in den Importmechnismen oder der Version der SQLite DLL (Ich habe nicht im Kopf, ob Du das hier irgendwo aufgeführt hast, welche SQLlite DLL / Delphiversion)

Vielleicht machst Du ja auch irgendwelche "kranken" Sachen im Import Code. Am Ende sind hunderte Connections zur DB offen oder Du hast irgendwo ein File Handle auf die SQLite geöffnet oder IDE (kann auch zur Designzeit die DB öffnen und offen halten) und Kompilat kommen sich in die Quere, .. es gibt viele Möglichkeiten.

Ist aber letztlich alles auch Rätselraten, wenn Dein (Import) Code hier unbekannt ist, ebenso wie die Importdaten.

[Peter-Pascal]

Vielen Dank an Jo und Delphi.Narium (was bedeutet dieser Nick? hoffentlich ist die Frage nicht zu unhöflich)

ich werde das mal der Reihe nach abarbeiten. Ich hatte gestern bereits ein Tool (HDDScan.exe) laufen lassen, hat aber keine Fehler gefunden. Möglicherweise liegt es doch an dem was ich zusammengeschrieben habe.

Trotzdem werde ich chkdsk noch laufen lassen.
Wobei ich das nicht verstanden habe, dass Windows dies beim Start ausführt, ich dachte ich öffen die DOS-Box oder wie die jetzt heißt, tippe die Buchstaben ein und los gehts.... und ich gehe Mittagsschlaf machen.

[Delphi.Narium]

Der Nick bedeutet genau nix, war nur Nonsen:

Als Kind hat mich das Delphinarium im Duisburger Zoo fasziniert. Heute hab' ich da eher ein "abstandhaltendes" Verhältnis zu, nachdem ich mal im Wuppertaler Zoo mitbekommen habe, wie hochgradig verhaltensgestört sich etliche der dort lebenden Tiere verhalten (und das bei artgerechter Haltung). Aber das geht jetzt am Thema vorbei

Vor der Rechtsschreibreform schrieb man Delfin noch Delphin. In Delphinarium kommt halt Delphi vor und um das "hervorzuheben" hab' ich 'nen Punkt zwischen Delphi und narium gemacht und da man nach 'nem Punkt, am Satzanfang, groß schreibt wurde daraus Delphi. Narium. Aber da im Nick kein Leerzeichen möglich war (oder ist?), hab' ich das weggelassen. Ist dann sowas wie "künstlerische Freiheit" oder so ähnlich. Soweit so Blödsinn

ChkDsk muss vor dem Windowsstart laufen, damit garantiert keine Datei von Wasoderwemauchimmer im Zugriff ist. ChkDsk benötigt absolut exklusiven Zugriff auf alles, da es ansonsten nicht möglich ist, beliebige Dateien bei Bedarf ganz oder teilweise zu lesen, geschweigedenn zu schreiben, um sie von Sektor X nach Sektor Y oder sonstwohin zu verschieben.

Zitat:

Möglicherweise liegt es doch an dem was ich zusammengeschrieben habe.

Das kann man natürlich nicht ausschließen, aber warum funktioniert es denn dann manchmal und manchmal nicht, und von SSD immer, aber von Festplatte nur zu ca. 80%? Dafür müsstes Du dann doch irgendeine "Zufallskomponente" in der Programmlogik haben, die nur unter bestimmten (bisher unbekannten) Umständen zu Fehlern führt.

Sprich: Wird die CSV stumpf und stur zeilenweise gelesen und in die DB geschrieben, oder gibt es da irgendwelche Abhängigkeiten, Daten die erst zur Laufzeit berechnet werden, Zeit- und/oder Datumswerte, die beim Import errechnet, hinzugefügt, ... werden, Zeichensatzkonvertierungen, ...?

Eventuell mal https://www.heise.de/download/produc...diskinfo-59349 anschauen und auch den Hinweisen auf weitere Software folgen.
Beim Hersteller der Festplatte mal nachschauen, ob er ein entsprechendes Werkzeug für seine Festplatten zur Verfügung stellt.

[Peter-Pascal]

Hallo Delphi.Narium,
Du hast Dir jedenfalls richtig Gedanken mit Deinem Nick gemacht. Ich habe einfach nur Pascal (wg Blaise Pascal) an meinen richtigen Vornamen gehängt.

Das Einlesen der CSV-Datei habe recht umfangreich gestaltet. Es sind ca. 1030 Zeilen, die hier zu veröffentichen etwas umfangreich wären.
Ich lese Bankdaten ein, also die Umsätze eines Bankkontos. Bevor ich die in die Datenbank speichere, werden die Daten erst in einem Grid dargestellt und der User kann die Spalten Datum, Betrag, Verwendungszweck ets. zuordnen. Gegebenenfalls können auch kleine Korrekturen vorgenommen werden, wenn sich in den Zahlen Buchstaben verirrt haben.
Erst dann werden die Daten aus dem Grid gelesen und pro Colum in je eine TList<T> gespeichert und in die jeweiligen Typen string, Datum, currency umgewandelt.
Wenn das ohne Fehler funktioniert schreibe ich die Daten in die DB. Der Buchungsatz besteht aus zwei Teilen. Die Kopfdaten enthalten das Datum, Verwendungszweck etc. und die Detaildaten nehmen das Konto hier Bank und den Betrag auf. (Ist wie bei SAP aufgebaut). Ein Fehler bei der Umwandlung wird mitgeteilt und es kann in dem Grid gesucht werden.
Und wenn es beim Speichern zum Fehler kam, dann hat das System ca. 500 Datensätze geschrieben, und irgenwann abgebrochen. Kopf und Detail stimmen überein und weitere 100 Datensätze fehlen. Konnte ich schon mal nachtragen, ebenfalls mit einer CSV.

Im nächsten Schritt kann dann der Buchungssatz vervollständigt werden.

Heute nachmittag oder gegen Abend starte ich mal Chckdsk und werde Dir schreiben, was sich ergeben hat.

Gegebenenfalls anschließend CrystalDiskInfo. Mal schauen was die mir erzählen.

Danke für Deine Tipps und die Links.