SQLite Dump mit FireDAC

[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 von 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?

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

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

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

[jobo]

Zitat von Mavarik:

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 von jobo:

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 von 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.

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).

[p80286]

Zitat von Mavarik:

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