DISQLite3 wandelt Feldtypen um?

[ryLIX]

Moin,
folgendes Problem stellt sich mir gerade:

Ich wollte mein Projekt auf DISQLite3 Komponenten umstellen.
Der Zugriff erfolgte bisher über ZEOS und funktioniert soweit gut bis auf die Tatsache das ich nicht auf verschlüsselte Datenbanken zugreifen kann.
Was ich aber möchte. Das geht mit DISQLite3 ohne Probleme...

Ich hatte mir nun ein Testprojekt zusammen gestellt und verwende dort die gleiche Datenbank und JvDBTreeView wie auch im Projekt welches umgestellt werden soll.
Nur wenn ich die Verbindung über die DISQLite3 Komponenten herstelle meldet mit JvDBTreeView das MasterField, DetailField und ImageField vom Typ Integer sein müssen. Sind sie auch :gruebel:

Da es mit den ZEOS Komponenten ohne Probleme Funktioniert liegt die Vermutung nahe das dieses Problem durch die DISQLite3 Komponenten verursacht wird.
Hat jemand von euch schon mal ein ähnliches Problem gehabt oder weiß eventuell warum das so ist?

Ich würde gern umstellen da ich die Verschlüsselung brauche und die DISQLite3 Komponenten auch den Vorteil haben das ich die DLL nicht mit liefern müsste (so hab ich das zumindestens verstanden :stupid: ).

[Bernhard Geyer]

Zitat:

Zitat von ryLIX

Da es mit den ZEOS Komponenten ohne Probleme Funktioniert liegt die Vermutung nahe das dieses Problem durch die DISQLite3 Komponenten verursacht wird.

Es wäre am besten ein kleine Testprogramm dem Hersteller zur Verfügung zu stellen.[/quote]

[Assertor]

Hi ryLix,

ich vermute, Du nutzt das DISQLite3DataSet (DISQLite3UniDirQuery), richtig?

Schau Dir mal das Demo in Demos\DISQLite3_ClientDataSet_Grid an, da siehst Du die DISqlite3UniDirQueryInitFieldDef. Mit hilfe dieser Methode kannst Du die Felddefinition überschreiben und z.B. auf Integer stellen.

Dann sollte das auch klappen :)

Gruß Assertor

[ryLIX]

Danke für den Hinweis.
Ich werde mich gleich mal auf die Suche danach begeben.

@Bernhard:
Ich hatte schon vermutet das es an den Einstellungen liegt da DISQLite3 (auch SQLite3) dir erlaubt z.B. in einem Integer Field einen String zu speichern.
Und die HTML Hilfe von DISQLite3 ist etwas undurchsichtig aufgebaut so das man damit noch schlechter zurecht kommt als mit der von VisualStudio :mrgreen:

:dp:

[ryLIX]

So hab das angesprochene gefunden :)

Nur bleibt mein DBTreeView leer. :|
Ich bin dem ganzen im Debug mal gefolgt.
DISQLite liest die Integer Felder als LargeInt aus.
Nur das Image Feld welche die ImageID für die ImageList enthält läd er als WideString :gruebel:
Macht aber dann die Umwandlung in Integer bzw String für die Beschriftung wie gewünscht.

Ich habe die Varianten mit ClientDataSet und ohne versucht.
Bei beiden bleibt das DBTreeView leer. :wall:
An der DB selber kanns wie gesagt eigentlich nicht liegen weil mit ZEOS wird alles wie gewünscht Dargestellt.

Ich frage mich gerade wieso nich einmal was einfach gehen kann :x

Edit:
Hier noch der Code. Das UniDirQuery wird in FormCreate geöffnet (zur DesignTime greift die Typenwandlung ja nicht).

Delphi-Quellcode:

procedure TForm2.DISQLite3UniDirQuery1InitFieldDef(
  const AColumn: TDISQLite3Column; const AFieldDef: TFieldDef);
begin
if AColumn.ColumnName='Master_ID' then
begin
  AFieldDef.DataType:=ftInteger;
end;
if AColumn.ColumnName='Parent_ID' then
begin
  AFieldDef.DataType:=ftInteger;
end;
if AColumn.ColumnName='Image' then
begin
  AFieldDef.DataType:=ftInteger;
end;
if AColumn.ColumnName='Name' then
begin
  AFieldDef.DataType:=ftString;
end;
end;

Edit2:
Bin mir nicht sicher woran es nun genau lag aber nun hab ichs. :gruebel:
Doof is nur das ich noch nich zurück verfolgen kann welche Einstellung genau den Erfolg gebracht hat.
Danke für die Hilfe :thumb:
:dp:

[Assertor]

Hi ryLIX,

Zitat:

Zitat von ryLIX

So hab das angesprochene gefunden :)

...

Edit2:
Bin mir nicht sicher woran es nun genau lag aber nun hab ichs. :gruebel:
Doof is nur das ich noch nich zurück verfolgen kann welche Einstellung genau den Erfolg gebracht hat.
Danke für die Hilfe :thumb:
:dp:

Bitte gerne - auch wenn es nur eine kleine Hilfe war und Du jetzt selbst die richtigen Einstellungen gefunden hast! Hauptsache das Problem ist gelöst :)

:dp:

Gruß Assertor

[ryLIX]

Ja nach der Lösung stehe ich nun vor ner gewissens Frage :D
DISQLite Personal hat kein VACUUM implentiert.
ZEOS keine Verschlüsselung. :roll:
So langsam vergeht mir die Lust an der Sache :(

[Assertor]

Hi ryLIX,

Zitat:

Zitat von ryLIX

Ja nach der Lösung stehe ich nun vor ner gewissens Frage :D
DISQLite Personal hat kein VACUUM implentiert.
ZEOS keine Verschlüsselung. :roll:
So langsam vergeht mir die Lust an der Sache :(

[offtopic]
Ja, das ist so eine Sache. Die (hast Du? bzw.) wirst Du häufig bei Komponenten haben, immer eine Abwägung von Interessen. Muß die Datenbank wirklich verschlüsselt werden, damit wird die Wartbarkeit ja auch erschwert.

Ich selbst nutze die DISQLite3 Professional, weil die Komponente eine sehr saubere, schnelle und stabile Umsetzung der SQLite3 API für Delphi bietet. Ich zahle mit der Lizenz praktisch dafür, daß mir jemand die Übersetzung von C zu Delphi abgenommmen hat und zusätzlich noch etliche (30+) Beispielprojekte liefert.

Wenn ich das auf meinen Stundenlohn umrechne, hat sich der Kauf für mich gelohnt.
[/offtopic]

Aber eine Idee: Wenn Du auf kostenlosen Komponenten aufsetzen mußt/willst, nutze doch ZEOS und verschlüssel die Daten selbst. Sprich Du speicherst in einer Spalte der Datenbank BLOB Daten, die in Deiner Anwendung von Dir selbst ver/entschlüsselt werden.

Dafür kannst Du dann z.B. das DEC nehmen.

Gruß Assertor

[ryLIX]

Ja das Problem liegt bei muss da ich derzeit auch finanziell nicht in der Lage bin auf kostenpflichtige Komponenten zu setzten.
Ich denke ich werde noch einen Versuch mit ZEOS und einer anderen Dll starten und sonst noch mal auf deine Lösung zurück kommen.

Denn eigentlich bräuchte ich beides.
VACUUM da der User einen Teil der Daten in der DB ändern darf und das AES Feature da er die anderen Daten nicht ändern darf/soll.
Die Wartung wäre kein Problem da bei mir die DB unverschlüsselt vorliegt und eigentlich erst zum Release durch das ReKey Feature verschlüsselt werden soll.

Es stehen eh noch einige Fragen im Raum aber dafür werde ich neue Thread verwenden da diese nicht zum Thema passen :)

[Assertor]

Hi,

Zitat:

Zitat von ryLIX

Ja das Problem liegt bei muss da ich derzeit auch finanziell nicht in der Lage bin auf kostenpflichtige Komponenten zu setzten.

Gut, dafür hab ich natürlich Verständnis. Wollte auch auch nur klarstellen, daß es ist eine gute Lösung ist :)

Zitat:

Zitat von ryLIX

Ich denke ich werde noch einen Versuch mit ZEOS und einer anderen Dll starten und sonst noch mal auf deine Lösung zurück kommen.

Denn eigentlich bräuchte ich beides.
VACUUM da der User einen Teil der Daten in der DB ändern darf und das AES Feature da er die anderen Daten nicht ändern darf/soll.
Die Wartung wäre kein Problem da bei mir die DB unverschlüsselt vorliegt und eigentlich erst zum Release durch das ReKey Feature verschlüsselt werden soll.

Es stehen eh noch einige Fragen im Raum aber dafür werde ich neue Thread verwenden da diese nicht zum Thema passen :)

Ok und Danke fürs Feedback!

Gruß Assertor