Fehlermeldung: "[FireDAC][Phys][SQLite] ERROR: disk I/O error."

Hi! :slight_smile:

Ich wollte gerade unsere kleine lokale Datenbank von einem Datenträger zu einem weiteren kopieren. Da tauchte die Fehlermeldung auf, dass die Quelldatei der Datenbankdatei selbst (sowie wenige Audiodateien) nicht vom Speichermedium gelesen werden können, also dass sich diese nicht kopieren lässt. Also hab ich mich dazu entschlossen, die Datenbank zu klonen. Als ich den Klonvorgang startete und der grüne Balken signalisierte, dass etwas passiert, erscheinte folgende Meldung:
[FireDAC][Phys][SQLite] ERROR: disk I/O error.

Was bedeutet das? Wie kann ich das beheben? Wo liegt der Fehler?

Liebe GrĂĽĂźe,
Niclas :slight_smile:

EDIT: Was ich vielleicht noch erwähnen sollte ist, dass die Datenbank uns derzeit keine Probleme bereitet und flüssig läuft.
EDIT 2: Trotz der Fehlermeldung wird die Datenbank dennoch geklont und ist als Datei auf dem neuen Datenträger vorhanden.

Hier gab es mal einen änlichen Fall, dort lag es daran, dass der Benutzer die Datenbankdatei in seinem Dropbox-Ordner (!) abgelegt hatte:

https://www.mairlist.com/forum/index.php?topic=8515.0

Es ist dennoch nicht auszuschlieĂźen, dass du dir die Datenbankdatei irgendwie zerschossen hast. Vielleicht an einer Stelle, die im normalen Betrieb nicht angefragt wird, wohl aber beim Klonen, wo ja alle Tabellen von vorne bis hinten ausgelesen und kopiert werden.

Vielleicht sicherheitshalber mittels dump/restore reparieren?

https://www.mairlist.com/forum/index.php/topic,7752.msg52766.html#msg52766

Nachtrag: Warum kopiert ihr nicht einfach die Datenbank-Datei mit dem Windows-Explorer? :wink:

Die Klon-Funktion ist eher nĂĽtzlich fĂĽr die Konvertierung Netzwerk -> lokal oder umgekehrt.

Danke fĂĽr die schnelle Antwort! :slight_smile:
Wenn ich die Datenbank über den Windows Explorer kopieren möchte, wird mir folgende Fehlermeldung angzeigt: “Die Quelldatei oder vom Quelldatenträger kann nicht gelesen werden.”
Wir speichern derzeit unsere kleine Datenbank auf einem dafür neu angeschafften 64GB 3.0 SanDisk-USB-Stick und möchten diese jetzt auf eine externe Festplatte kopieren. Der USB-Stick hat schon öfters Probleme bereitet und auch bei mehreren Musiktiteln wird bei der Kopie diese Meldung ausgespuckt, obwohl diese fehlerfrei sind und einwandfrei funktionieren. Wäre es denkbar, dass der USB-Stick fehlerhaft ist? Und viel wichtiger: Wie können wir die Datenbank (die sich immer noch problemlos und ohne Warnmeldungen ausführen lässt) sicher und ohne Verluste auf die externe Festplatte kopieren?

Sieht wirklich so aus, als sei der Stick defekt.

Macht einen Dump mit anschlieĂźendem Einspielen in eine neue Datenbankdatei, siehe Link oben.

Und bitte legt die Datenbankdatei immer auf die interne Platte! SQLite mag weder externe Laufwerke noch Netzlaufwerke so gerne, da ist Ă„rger vorprogrammiert.

Mist, aber gut, dass es eine Lösung gibt. :slight_smile:

Was ist der neue Begriff in SQLite3 anstatt .open, denn der ist bei mir auch nicht (mehr) verfĂĽgbar und in dem verlinkten Thread hab ich keinen neuen Befehl dafĂĽr gesehen.

Das mit der internen Festplatte ist bei uns ein kleines Problem. Wir sind ein neues Schulradio und arbeiten momentan noch mit der Demo-Version. Da wir genug Sponsoren gefunden haben, können wir in den nächsten Tagen endlich eine Lizenz kaufen und den Sendebetrieb starten (wie ich dir vor einigen Wochen bereits in einer eMail geschrieben hab). Diese Lizenz wird auf dem Rechner in unserem Studio in der Schule aktiviert. Da wir aber unsere Pausensendungen meistens zuhause Planen werden müssen, müssen wir auch zuhause Zugriff auf die Datenbank haben können, denn ausschließlich zur Sendeplanung reicht zuhause die Demo-Version ja eigentlich aus. Aus diesem Grund muss unsere Datenbank mobil sein, damit wir sie zuhause und in der Schule anschließen können. Oder gibt es da eine andere Möglichkeit?

Datenbankdatei per Batchdatei auf den Stick/Festplatte kopieren bzw. wieder zurĂĽck.

Ihr könnt das mit der externen Platte natürlich mal probieren. Vielleicht funktioniert es. Aber macht auf jeden Fall regelmäßige Backups!

Bezüglich .open: Bei sqlite3.exe-Versionen, die das (noch?) nicht können, startet man sqlite3 einfach auf der Windows-Kommandozeile und übergibt dabei den Namen der Datenbankdatei:

sqlite3.exe database.mldb

Edit: Oder hier eine neuere sqlite3.exe herunterladen: https://www.sqlite.org/download.html

(Unter “Precompiled Binaries for Windows” und dort unter “A bundle of command-line tools for managing SQLite database files, including the command-line shell program, the sqldiff.exe program, and the sqlite3_analyzer.exe program.”)

Hi :slight_smile: Danke fĂĽr Deine schnelle Hilfe.

Tut mir leid, wenn ich wieder nachhaken muss:

Wie funktioniert das? ??? Bzw. wie erstellen wir diese Batchdatei? Wir kennen uns da gar nicht gut aus. Das Ergebnis soll dann sein, dass wir unsere Datenbank vom Studiorechner, auf dem dann auch die Audiodateien gespeichert werden, auf einen Stick verschieben, zuhause die Sendungen planen können (für die wir ja die Audiodateien an sich nicht brauchen) und dann zur Durchführung der Sendung wieder auf den Studiorechner schieben? Und diese besagte Batchdatei soll dieses Verschieben dann regeln? Hab ich das so richtig verstanden - als Alternative zur permanenten Speicherung von Datenbank und Audiodateien auf einem externen Datenträger?

Jetzt versuche ich erstmal unsere Datenbank mit sqlite3 zu retten… :slight_smile:

ERGEBNIS: Die Datenbankrettung scheint nicht funktioniert zu haben. Bei Dump (Schritt 3) tauchten, wie beschrieben, einige ERRORs auf, die ja in Ordnung sein sollen, allerdings ist die neue Datenbank weiterhin leer. Ich hab die neue Datenbank auf einer externen Festplatte erstellt, da der Stick ja fehlerhaft zu sein scheint. Daraufhin habe ich die dump.txt und sqlite3.exe auf die Festplatte kopiert um dort das Integrieren der dump.txt in die neue (leere) Datenbank durchzuführen. Leider ohne Erfolg… :frowning:

Ich habe die Fehlermeldungen hier mal angefĂĽgt:

Die originale Datenbank hieß STILECHT_RADIO_DATABASE.mldb. Die hab ich dann in originalSTILECHT_RADIO_DATABASE.mldb unbenannt, dann wie gesagt eine neue Datenbank erstellt, die ich dann wieder STILECHT_RADIO_DATABASE.mldb benannt habe. Aber es funktioniert nicht… :frowning:

Torben hat oben noch geschrieben.

Und bitte legt die Datenbankdatei immer auf die interne Platte! SQLite mag weder externe Laufwerke noch Netzlaufwerke so gerne, da ist Ă„rger vorprogrammiert.

Versuch erstmal lokal. Vielleicht ist das das Problem. Glaube es aber weniger.

Die dumb.txt hast du ja, richtig? Die hat auch den ungefähren Inhalt des in Torben gezeigten Threads, richtig? Bei dir macht also Schritt 5 Probleme, oder wie?
Btw. in dem Thread zur Datenbankreparatur siehst du im letzten Thread auch, welche Befehle Torben eingegeben hat und welche Fehlermeldungen kamen etc.

Die Meldungen bedeuten, dass die Tabellen, die du versuchst anzulegen, schon existieren.

Du darfst die neue Datenbankdatei nicht mit der mAirList-Funktion “Neue Datenbankdatei anlegen” erstellen! Sonst hast du die Tabellendefinitionen doppelt, was zu den genannten Fehlermeldungen führt.

Stattessen einfach “.open irgendeinneuerdateiname.mldb” machen, wobei diese neue Datei zu dem Zeitpunkt noch nicht existieren darf. SQlite legt sie dann für dich an.

Am Ende kannst du sie mit “Bestehende Datenbank öffnen” in mAirList einbinden.

Achsoooo DANKE! :slight_smile: Ich versuche es sofort nach dem Unterricht. Die dump.txt kann auch eigentlich nicht fehlerhaft sein, die ist nämlich voller Titelnamen und deren Cue/Hook and so on Werte und Playlisteninhalte konnte ich da auch identifizieren. :slight_smile:

Hi! :slight_smile: Es gibt schlechte Nachrichten.
Die durch sqlite erstellte neue Datenbank (database.mldb nannte ich sie) funktioniert auch nicht. Die dump.txt Datei wird zwar anscheinend gelesen, allerdings passiert nichts weiter. Kurzfristig erscheint eine zusätzliche Datei (database.mldb-journal), die beim schließen von squlite3.exe wieder verschwindet. Die Datenbank hat dauerhaft eine größe von 0KB und als ich sie dennoch als Datenbank in mAirList einfüge, kommt die Fehlermeldung, dass keine Tabellen enthalten sind, was ja eigentlich klar war.

Was jetzt? Ich kann die dump.txt gerne mal hochladen. :slight_smile:

Ja, lade die Dump-Datei mal hoch.

Für uns hat sich die Sache derzeit eigentlich erledigt, wir haben uns am Wochenende eine neue externe Festplatte zugelegt und darauf eine neue Datenbank erstellt. Die nötigen Playlisten hatten wir ja Gott sei Dank gesichert, somit war der entstandene Mehraufwand nicht all zu groß. :slight_smile: