Hallo,

wenn ich das Beispiel der SQlite-Datenbankverschlüsselung richtig verstehe, wird bei einer bestehenden Datenbank per FDSQLiteSecurity1 nur das Passwort und der Verschlüsselungsalgorithmus gesetzt und damit ist die DB dann "von außen" nicht mehr lesbar...

Nach dieser (einmaligen) Aktion wird dann mit der DB gearbeitet indem der FDConnection Passwort und Verschlüsselung beim Öffnen mitgegeben werden:

markieren

Delphi-Quellcode:

    FDConnection1.Params.DriverID := 'SQLite';
    FDConnection1.Params.Database := edtPath.Text;
    FDConnection1.Params.Values['Encrypt'] := cbMode.Items[cbMode.ItemIndex];
    FDConnection1.Params.Password := edtPwd.Text;

Ist das soweit richtig?

Ciao
Stefan

Yepp.
Kurze Antwort, aber so mache ich es auch.
Wichtig ist nur, das Passwort dann gut genug zu verschlüsseln, sonst hast Du ggf. eine nach allen Regeln der Kunst z.B. mit AES256 verschlüsselte SQLite-DB, aber dennoch keinen guten Schutz, weil das Passwort irgendwo auftaucht, wo es das nicht sollte.

Danke, wieder ein Problem weniger

Ciao
Stefan

Eine Nachfrage hätte ich da noch:

Mit
FDSQLiteSecurity.CheckEncryption; bekomme ich ja den aktuellen Status der Datenbank, aber wenn ich vorher das Passwort setze bekomme ich Laufzeitfehler wenn die DB noch unverschlüsselt ist, setze ich das Passwort in FDSQLiteSecurity nicht und frage den Status ab bekomme ich einen Laufzeitfehler wenn die DB bereits verschlüsselt ist.

Diese Fehler treten im Beispiel nicht auf!
Ich erzeuge aber meine Komponenten zur Laufzeit und habe alle möglichen Properties des Beispiels kontrolliert, finde aber nicht die Stelle wo man die Exception verhindern kann!

Hat hierzu noch jemand eine Idee?

Ciao
Stefan

Hatte ich am Anfang auch...

Problem war die Reihenfolge...

Ich hab das hinbekommen - bin gerade nicht an meinem Rechner...

Workaround... :

Wenn die Datenbank verschlüsselt ist eine Datei BaseName.SCR anlegen... (Ohne Inhalt)

if Fileexists(Basename+'.SCR') then... Ich schau aber gerne noch nach der "richtigen" Lösung.

Mavarik

Ja bitte schau mal!

Das mit der leeren Datei als Workaround habe ich nicht verstanden...

Ciao
Stefan

Nachtrag:
Jetzt habe ich es kapiert, ist die Datei (egal wie sie heißt) vorhanden, soll das Programm davon ausgehen dass die DB verschlüsselt ist?
Funktioniert aber nur eingeschränkt!
Wenn die DB z.B. gelöscht wird, wird sie beim ersten nächsten Zugriff wieder neu erst mal unverschlüsselt erstellt und die Kennzeichnungsdatei ist immer noch vorhanden...!

Zitat von sko1:

Funktioniert aber nur eingeschränkt!
Wenn die DB z.B. gelöscht wird, wird sie beim ersten nächsten Zugriff wieder neu erst mal unverschlüsselt erstellt und die Kennzeichnungsdatei ist immer noch vorhanden...!

Deswegen eine Class Methode Kill, die beide Dateien löscht.

Wenn da manuell was gelöscht wird hilft die Class-Methode auch nicht..

Ciao
Stefan

Emba erklärt es ein wenig anders als Du beschreibst, vielleicht nochmal lesen und korrekt anwenden? Ich mein, eventuell hast Du einen Fehler im Code.
Funktion FireDAC.Phys.SQLite.TFDSQLiteSecurity.CheckEncryption gibt als Ergebniss

Zitat:

<unencrypted> = The database is not encrypted.
For example: aes-256 = The database is encrypted and the correct password is specified.
<encrypted> = The database is probably encrypted, but the specified password is not correct.
empty string = Some other error happened at encryption checking.

Ich kann nur wiederholen was da steht da ich selbst gerade an SQLite3 rumbastel allerdings ohne FireDAC/AnyDAC/UniDAC etc sondern nativ.

edit
RAD Studio Demo Code, vielleicht hilft Dir das.

Zitat von sko1:

Wenn da manuell was gelöscht wird hilft die Class-Methode auch nicht..

Ciao
Stefan

Wo ist das Problem, vor einer Neuanlage die Reste zu löschen?