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.
Zitat
Baum-Darstellung
