SQLite Dump mit FireDAC

[Mavarik]

Hallo Zusammen!

Kann es sein, dass es mit FireDAC nicht möglich ist einen Dump einer SQLite Datenbank in eine Textdatei zu machen?

Muss man hierfür das sqlite3 Commandlinetool benutzen?

Finde ich es nur nicht oder gibt es kein TFDDump oder sowas?

Mavarik

[himitsu]

Das Problem ist, dass leider nicht das DBMS den DUMP generiert, sondern die Client-Komponente.
Da müsste also TFDDump alle möglichen DBMS und deren Besonderheiten mit sich rumschleppen, um einen korrekten SQL-Dump generieren zu können.

Drum gibt es vielleicht auch keine Komponente dafür?

[Mavarik]

Zitat:

Zitat von himitsu (Beitrag 1369614)

Das Problem ist, dass leider nicht das DBMS den DUMP generiert, sondern die Client-Komponente.
Da müsste also TFDDump alle möglichen DBMS und deren Besonderheiten mit sich rumschleppen, um einen korrekten SQL-Dump generieren zu können.

Drum gibt es vielleicht auch keine Komponente dafür?

Gut, also gibt es keinen Zugriff auf den SQLite Dump?! :stupid:

Es könnte ja über den Phy.Sqlite.Driver gehen...

Kann ich den das Dump Kommando nativ an die SQLite.Dll senden?

[jobo]

Zitat:

Zitat von Mavarik (Beitrag 1369616)

Kann ich den das Dump Kommando nativ an die SQLite.Dll senden?

Was ist "nativ" für Dich?
Schau mal hier of SO, vielleicht brauchbar für Deine Zwecke:
http://stackoverflow.com/questions/7...sqlite3-tables

1.Antwort

Zitat:

I would use the following to get a CSV file, which I can import into almost everything..

..snip..

If you want to reinsert into a different SQLite database then:
..snip..

[Mavarik]

Zitat:

Zitat von jobo (Beitrag 1369633)

Was ist "nativ" für Dich?
Schau mal hier of SO, vielleicht brauchbar für Deine Zwecke:
http://stackoverflow.com/questions/7...sqlite3-tables

Genau das ist was ich nicht will... Ich möchte sicherlich nicht extra auf einem Kundenrechner ein Commandlinetool installieren.

Ich möchte innerhalb meiner Software für den Fall das der Check einen Fehler meldet, einfach "nur" die Datenbank per Dump in einen Stream / TStringlist exportieren um danach eine neue Datenbank mit diesen Informationen zu füttern.

[Ghostwalker]

Du könntest dir via SQlite-Api eine Dump-Funktion bauen.

Dazu:

1. Schritt: Tabellen analysieren und entsprechende Create-Statements bauen -> ab in die textdatei damit
2. Schritt: Aus den Daten entsprechende Insert-Statemnts bauen -> ab in die Textdatei damit

feddich is der Dump.

[Mavarik]

Zitat:

Zitat von Ghostwalker (Beitrag 1369745)

Du könntest dir via SQlite-Api eine Dump-Funktion bauen.

Dazu:

1. Schritt: Tabellen analysieren und entsprechende Create-Statements bauen -> ab in die textdatei damit
2. Schritt: Aus den Daten entsprechende Insert-Statemnts bauen -> ab in die Textdatei damit

feddich is der Dump.

OK... Vielleicht habe ich es falsch verstanden - wenn man nach SQLite Repair googled bekommt man immer als Antwort ein Repair gibt es nicht - was eigentlich schon der tot in meinen Augen ist, aber lassen wir das mal außer Acht - Als Möglichkeit wird immer gesagt - Dump -> Neue Datenbank... Wenn der Dump nicht mehr kann als ich mit einem Select *, dann ist das natürlich für die Katz. Es geht ja darum aus einer defekten SQLite Datei die Nativen Daten zu holen...

[Ghostwalker]

Wenn die Datei schon zerbröselt ist (physikalisch), wirst du da ganz schlechte Karten haben.

Du kannst natürlich versuchen, die Datei als ganz normale Binär-Datei zu handhaben und das ganze
selbst zu analysieren und versuchen zu retten was zu retten ist. Das Dateiformat ist

http://www.sqlite.org/fileformat2.html hier
beschrieben. Aber ob der Aufwand das ganze wert ist, steht auf einem anderen Blatt.

Ich persönlich würde, bevor es passiert, lieber eine autom. Backup-Funktion einbauen (siehe Backup-Extension von SQlite).

[Mavarik]

Zitat:

Zitat von Ghostwalker (Beitrag 1369762)

Ich persönlich würde, bevor es passiert, lieber eine autom. Backup-Funktion einbauen (siehe Backup-Extension von SQlite).

Wie oft willst Du den ein Backup machen? Und wohin? Auf die ggf. gleiche defekt externe USB-Platte?
Oder auf einen Stick den der User erst einlegen muss?

[Ghostwalker]

Zitat:

Zitat von Mavarik (Beitrag 1369765)

Zitat:

Zitat von Ghostwalker (Beitrag 1369762)

Ich persönlich würde, bevor es passiert, lieber eine autom. Backup-Funktion einbauen (siehe Backup-Extension von SQlite).

Wie oft willst Du den ein Backup machen? Und wohin? Auf die ggf. gleiche defekt externe USB-Platte?
Oder auf einen Stick den der User erst einlegen muss?

<IRONIE>
Wohin willst du den den Dump machen ? Auf die gleiche defekte externe USB-Platte ? oder auf einen Stick
den der User erst einlegen muss ?
</IRONIE>

Sorry.

Wenn die ganze Platte geschrottet ist, brauchst du keinen Dump mehr, denn dann hast du erstmal das Problem überhaupt auf die Platte zugreifen zu können.

Wohin man ein Backup spielt, ist davon abhängig, welche Gegebenheiten man hat. Ist ein Netzwerk (evtl. mit Server) vorhanden ? ist eine Internetverbindung vorhanden ? Welche Platten sind vorhanden ? Gibt es einen CD-/DVD-Brenner ? Gibt es einen Streamer ?

Es ist auch Abhängig für welche Zielgruppe dein Projekt ist (eher privater Nutzer oder Firma).

Ich versuch hier lediglich dir eine Alternative auf zu zeigen, so das sich das Problem einer Reparatur garnicht erst stellt. :)

[p80286]

Zitat:

Zitat von Mavarik (Beitrag 1369759)

OK... Vielleicht habe ich es falsch verstanden - wenn man nach SQLite Repair googled bekommt man immer als Antwort ein Repair gibt es nicht - was eigentlich schon der tot in meinen Augen ist, aber lassen wir das mal außer Acht

Bei Repair und Datenbank fällt mir immer nur DBase, Access und Clipper ein. Nicht umsonst werden die nicht unbedingt ernst genommen. Eine richtige Datenbank wird nicht repariert, da wird zb. ein Index neu erstellt, oder Sie wird aus ihrem Dump/Backup neu erstellt.
Falls es da wirklich zu "Bröselerscheinungen" kommen sollte, wäre es an der Zeit die Qualität der eingesetzten Hard und Software zu hinterfragen.
Von den og bin ich es gewohnt, daß sie über kurz oder lang Ausfallerscheinungen zeigen/zeigten. "Richtige DBMS" sind da durchaus zuverlässiger, Es sei denn sie befinden sich auf einer lokalen Festplatte, mit einem Benutzer vor der Tastatur, der immer noch ein Anhänger des BigRedKnob ist.

Gruß
K-H

[Mavarik]

Zitat:

Zitat von p80286 (Beitrag 1369786)

Bei Repair und Datenbank fällt mir immer nur DBase, Access und Clipper ein. Nicht umsonst werden die nicht unbedingt ernst genommen. Eine richtige Datenbank wird nicht repariert, da wird zb. ein Index neu erstellt, oder Sie wird aus ihrem Dump/Backup neu erstellt.
Falls es da wirklich zu "Bröselerscheinungen" kommen sollte, wäre es an der Zeit die Qualität der eingesetzten Hard und Software zu hinterfragen.
Von den og bin ich es gewohnt, daß sie über kurz oder lang Ausfallerscheinungen zeigen/zeigten. "Richtige DBMS" sind da durchaus zuverlässiger, Es sei denn sie befinden sich auf einer lokalen Festplatte, mit einem Benutzer vor der Tastatur, der immer noch ein Anhänger des BigRedKnob ist.

In einer heilen Welt wo jeder User sich mit seinem PC, dem Netzwerk, dem NAS und dem Betriebssystem auskennt, sind Deine Aussagen alle richtig...

Jede Filebasierte Datenbank hat jedoch das Problem, das Zugriffe nicht richtig serialisiert werden können.

Welcher User macht schon Datensicherungen?

Wenn ich also mit meiner Wechselfestplatte immer zwischen zu Hause und meinen Büro pendele, kann es mal zu einen Lesefehler kommen... Wenn dann dadurch die ganze Datenbank nicht mehr erreichbar ist - ist das schlecht... Es soll - wenn überhaupt nur der Datensatz defekt sein, der auch in dem Sektor gespeichert wurde...

Bei einer Bin-Datei kann ich einfach durch seeken...

Delphi-Quellcode:

for i:=0 to Sizeof(Datei) div RecordSize do
  begin
    try
      seek(I*RecordSize);
      read...
      writeNewDB;
    except
      RecordIgnorieren
    end;
  end;

Oder ich schreibe an jeden Record Anfang ein Magic - welches ich in einer zerstörten Datei finden kann...

Ich wollte jetzt aber nicht das Dateiformat von SQLite nach programmieren...

Mavarik 8-)

Ich ziehe die Frage hiermit zurück... :stupid:

[himitsu]

Ist bei den kleineren Dingern DBMS nicht eh jede Daenbank oder gar Tabelle eine eigene Datei?

Da kannst du doch auch im Programm regelmäßig ein Backup machen, indem die die Datenbank oder die einzelnen Tabellen klonst.
Und bei Problemen eine ältere Version zurück spiels.
https://www.tutorialspoint.com/sql/s...ing-tables.htm

Modernere DBMS arbeiten mit Transaktionen, wo änderungen erstmal in ein transaktionslog kommen, dann wird dieses Log in die Hauptdatei übernommen und erst wenn fertig, dann wird das Log gelöscht.
Wenn man als bei Schreibvorgängen was kaputt macht (RoterKnopf, SteckerZiehn usw.), dann gibt es immer mindestens einen konsitenten Zustand und das DBMS kann abgebrochen Schreibforgänge wiederholen (reparieren), bzw. maximal die allerletzte Transaktion könnte verschwinden, wenn sie noch nicht vollständig gespeichert wurde.
(Fehler am Datenträger, bzw. Änderungen während das DBMS offline war, mal ausgeschlossen)