Leere Vorgabedatenbank

[sko1]

Hallo,

in meinem Windows/Android-Projekt arbeite ich mit einer SQLite-Datenbank.
Diese wird bei Installation als leere Datenbank (ohne Tabellen usw.) angelegt und dann im Programm die Tabellen usw. erzeugt.

Jetzt bin ich am Suchen wie man
a) die leere Datenbank gleich irgendwie in die EXE verpacken kann oder
b) eine leere Datenbank per Code erstellen kann, bisher habe ich dafür den "DB Browser für SQLite" verwendet.

Ciao
Stefan

[Union]

Die Datenbank wird beim Öffnen der Verbindung automatisch erstellt, falls sie nicht existiert. Das Vorgehen mit einer leeren Vorgabedatenbank war eigentlich überflüssig.

[DeddyH]

Ich mache es immer so, dass ich eine TFDConnection einrichte und dieser zur Laufzeit (BeforeConnect) den Datenbanknamen zuweise.

Delphi-Quellcode:

procedure TMeinDataModule.LocalConnectionBeforeConnect(Sender: TObject);
const
  LOCALDBNAME = 'MeineDB.s3db';
begin
  LocalConnection.Params.Values['Database'] :=
    TPath.Combine(ConfigPath, LOCALDBNAME);
end;

[Der schöne Günther]

Ich nehme das Freeware-Tool meines Vertrauens "SQLite Expert" und lege damit meine gewünschte Struktur an. Zeitgleich kann er mir ein Buildscript daraus generieren, also wie man diese Tabellen und Regeln per SQL anlegen würde. Das kann aber sicherlich jedes andere Tool auch.

Wenn beim Programmstart die Datenbank nicht existiert nimmt das Programm dieses hinterlegte Skript und führt es aus. Dann habe ich meine erwartete Tabellenstruktur und bin fertig. Optional könnte dieses Buildskript schon Beispieldaten enthalten wenn man z.B. einen Demo-Modus haben möchte...


Praktisch habe ich eine Variable mustRunBuildScript die im OnBeforeConnect-Event der Verbindung auf True gesetzt wird wenn die Datenbank nicht existiert. Im OnAfterConnect-Event wird dann, wenn die Variable true ist, das Buildscript über TFDConnection.ExecSQL(..) ausgeführt.

Delphi-Quellcode:

procedure TStorageModuleSqlite.runBuildScript();
const
   fileName = 'buildscript_sqlite.sql';
var
   filePath: String;
begin
   filePath := TPath.Combine('...', fileName);
   connection.ExecSQL( TFile.ReadAllText(filePath) );
   mustRunBuildScript := False;
end;

[sko1]

Zitat von Union:

Die Datenbank wird beim Öffnen der Verbindung automatisch erstellt, falls sie nicht existiert. Das Vorgehen mit einer leeren Vorgabedatenbank war eigentlich überflüssig.

OOOOOHHHHHH!
Da mach ich "Kopfstände" und es ist sooo einfach!

Vielen herzlichen Dank für's "Brett vor dem Kopf entfernen"!

Unter Windows wird die DB problemlos erstellt, Android teste ich dann in Folge

Ciao
Stefan

[p80286]

Zitat von Der schöne Günther:

Ich nehme das Freeware-Tool meines Vertrauens "SQLite Expert" und lege damit meine gewünschte Struktur an. Zeitgleich kann er mir ein Buildscript daraus generieren, also wie man diese Tabellen und Regeln per SQL anlegen würde. Das kann aber sicherlich jedes andere Tool auch.

Wenn beim Programmstart die Datenbank nicht existiert nimmt das Programm dieses hinterlegte Skript und führt es aus. Dann habe ich meine erwartete Tabellenstruktur und bin fertig. Optional könnte dieses Buildskript schon Beispieldaten enthalten wenn man z.B. einen Demo-Modus haben möchte...


Praktisch habe ich eine Variable mustRunBuildScript die im OnBeforeConnect-Event der Verbindung auf True gesetzt wird wenn die Datenbank nicht existiert. Im OnAfterConnect-Event wird dann, wenn die Variable true ist, das Buildscript über TFDConnection.ExecSQL(..) ausgeführt.

Delphi-Quellcode:

procedure TStorageModuleSqlite.runBuildScript();
const
   fileName = 'buildscript_sqlite.sql';
var
   filePath: String;
begin
   filePath := TPath.Combine('...', fileName);
   connection.ExecSQL( TFile.ReadAllText(filePath) );
   mustRunBuildScript := False;
end;

Abgesehen davon, daß ich das gut finde, prüfst du auch ob die Datenbank, die du findest, falls eine vorhanden sein sollte, auch die richtige ist?

Gruß
K-H

[Der schöne Günther]

Verstehe ich nicht: Wie ist denn eine Datenbank die "richtige"? Oder was wäre eine "falsche" und warum sollte sie dort liegen wo das Programm sie erwartet?

[p80286]

Na die richtige ist die, mit den erwarteten Tabellen und Feldern in den Tabellen.
z.B. könnten Versionsunterschiede (zus. Felder oder fehlende Felder / Typänderungen) Dein Programm ja etwas verwirren.

Gruß
K-H

[Der schöne Günther]

Das meinst du. Guter Punkt!

Ich habe eine Tabelle in welcher die "Versionsnummer" drin steht. Wenn die Datenbank-Version jetzt z.B. "1.4" ist, die Software nach einem Update aber nun mit einer Version "1.5" arbeiten möchte ... ja, dann führt sie noch ein Skript aus welches die Datenbank-Struktur von "1.4" auf "1.5" updatet.

[sko1]

Genau so mache ich das auch und dank der Tips hier muss ich keine leere Datenbank mehr als Grundausstattung "mitliefern"...

Ciao
Stefan