SQLite Treiber dbx Emba XE6 SP1 immer noch nicht zu gebrauchen

[arnof]

Hallo,

z.Z. bin ich echt gezwungen EMBA Basching zu machen!

Der seit XE3 angebotene SQLite Treiber ist immer noch unfassbar und nur für die Mülltonne!

Alle Felder gibt der im TDataSet als TWideMemo zurück, egal welcher Datentype das auch sein mag.

Leute Leute schon seit 3 Hauptversionen so was anzubieten ist schon Mobbing für Entwickler 3.0

Hat jemand ein Tipp, geht Firedac besser ?

[Bernhard Geyer]

DbX ist seit der übernahme von AnyDac (jetzt FireDac) gestorben.
Da wird auch nix mehr kommen. Sehe DBX als BDE 2.0 an. Wird zwar noch Jahrelang mitgeliefert, aber nix mehr angepasst/gefixt.

[Der schöne Günther]

Ich bin in Sachen Datenbanken ein hoffnungsloser Fall, aber ich verstehe nicht ganz: Was ist zurückgeben: Ich hatte (als ich noch dbx genutzt hatte) eine SQLite-DB drin und mir auf dem Formular-Designer die DB einmal zur Entwurfszeit verbunden und dann einmal dieses "Alle Felder hinzufügen" gemacht. Jeglichen Text hatte er zwar immer als WIDEMEMO eingeschraubt und ich konnte zur Entwurfszeit in Dingen wie dem TDBGrid nichts mehr sehen, aber andere Typen hatte er richtig.

Soweit ich mich erinnern konnte war das XE4. Oder meinst du etwas anderes?

// Update:
Ich sehe aber auch grade: Was erwartest du denn genau? Bei mir werden INTEGER-Felder auch als TLargeIntField (oder so ähnlich)-Felder eingebunden. Sonst so ziemlich alles als TWideMemoField. Das finde ich eigentlich verständlich da SQLite doch auch nichts anderes kennt als

1. NULL
2. INTEGER
3. REAL
4. TEXT
5. BLOB

Habe ich mich auch etwas mit herumgeärgert, einen Timestamp immer als String zu bekommen. Aber so ist das doch in SQLite nunmal, oder?

[arnof]

ja jedes Feld ist vom Type ftWideMemo, diese zeigt er auf den ersten Blick richtig an. Mit Livebindings kann er aber keine Datumsfelder befüllen! Deshalb habe ich mal genauer geschaut. Die Datenbank ist mit diesem Treiber so, wie wenn Sie ein Praktikant, der noch nie was von Datenbankdesign gehört hat angelegt hätte.

Sowas kann man keinen Kunden und noch nicht mal inhouse anbieten, nun bin ich wieder an dem Punkt, wo ich mit XE3 war. Man läßt es am besten einfach bleiben!

Das will ich aber nicht mehr, deshalb versuche ich nun FireDac, mal schauen was für Bugs mich da nerven!

[Der schöne Günther]

Ich habe grade nochmal auf ein Datenmodul geschaut dass ich erst mit DBX gemacht hatte und später dann mal komplett gegen FireDAC getauscht hatte. Die DBX-Komponenten sind noch drauf.

Die DBX-Felder sind tatsächlich alle WideMemo, FireDAC war so schlau und gleich überall TimeStamp-Felder, Booleans und AutoIncs erkannt. Nicht übel.

[Sir Rufo]

Da jedes Datenbank-System sein eigenes Süppchen kocht (Datum, Boolean, Texte, etc.) und auch die Verbindungen das immer etwas anders interpretieren, würde ich empfehlen die Anwendungs- bzw. UI-Schicht nicht direkt mit der Datenbank zu verbinden.

"Einfach" die Daten für die Anwendungs-Schicht in Klassen (Model) zusammenfassen, für die UI-Schicht anderen Klassen (ViewModel) und für den Austausch mit der Daten-Schicht ein DTO (DataTransferObjekt) inkl. Assembler (Model <-> DTO).

Ist zugegebenermassen mehr Aufwand als einfach eine Query hinklatschen und mit LiveBinding zu verbinden, dafür hat man aber alles in der Hand und jede Menge Spielraum für die Implementierung ohne sich ständig ins Knie zu schießen.

[arnof]

Zitat:

Zitat von Sir Rufo (Beitrag 1268346)

Da jedes Datenbank-System sein eigenes Süppchen kocht (Datum, Boolean, Texte, etc.) und auch die Verbindungen das immer etwas anders interpretieren, würde ich empfehlen die Anwendungs- bzw. UI-Schicht nicht direkt mit der Datenbank zu verbinden.

"Einfach" die Daten für die Anwendungs-Schicht in Klassen (Model) zusammenfassen, für die UI-Schicht anderen Klassen (ViewModel) und für den Austausch mit der Daten-Schicht ein DTO (DataTransferObjekt) inkl. Assembler (Model <-> DTO).

Ist zugegebenermassen mehr Aufwand als einfach eine Query hinklatschen und mit LiveBinding zu verbinden, dafür hat man aber alles in der Hand und jede Menge Spielraum für die Implementierung ohne sich ständig ins Knie zu schießen.

wenn der SQLTreiber nur "Müll" zurückgibt, da nützt die ... nichts!

[Sir Rufo]

Zitat:

Zitat von arnof (Beitrag 1268348)

wenn der SQLTreiber nur "Müll" zurückgibt, da nützt die ... nichts!

ganz kaputt kann man nicht heilen aber mit wesentlich geringerem Aufwand den Daten-Layer auf einen anderen Connector umstellen oder auch gleich eine andere DB :)

Aber so wie du geschrieben hast kommen die Daten doch an (als WideMemo)... mit dem passenden DTO/Assembler kannst du das trotzdem dann verarbeiten ;)

[Mschmidt]

Alternativen Suchen?
Ich verwende seit Jahren UniDac von Devart. Damit geht so ziemlich alles was Mainstream-Datenbanken betrifft. Ist aber leider nicht gratis.
Zumal man, wenn das Db-Design stimmig ist, über ein einfaches Property die Datenbank wechseln kann.
vg. Mathias

[Harry Stahl]

Zitat:

Zitat von Sir Rufo (Beitrag 1268346)

Da jedes Datenbank-System sein eigenes Süppchen kocht (Datum, Boolean, Texte, etc.) und auch die Verbindungen das immer etwas anders interpretieren, würde ich empfehlen die Anwendungs- bzw. UI-Schicht nicht direkt mit der Datenbank zu verbinden.

"Einfach" die Daten für die Anwendungs-Schicht in Klassen (Model) zusammenfassen, für die UI-Schicht anderen Klassen (ViewModel) und für den Austausch mit der Daten-Schicht ein DTO (DataTransferObjekt) inkl. Assembler (Model <-> DTO).

Ist zugegebenermassen mehr Aufwand als einfach eine Query hinklatschen und mit LiveBinding zu verbinden, dafür hat man aber alles in der Hand und jede Menge Spielraum für die Implementierung ohne sich ständig ins Knie zu schießen.

Das ist ein Thema, dass mich sehr interessiert (eigentlich müsste man dazu mal einen eigenen Thread aufmachen). Spätestens wenn man Crosscompile-Projekte macht, merkt man, wie wichtig es ist, Oberfläche und Datenschicht / Anwendungslogik zu trennen.

Was Du hier ansprichst, geht ja auch noch einen Schritt weiter, nämlich die Verarbeitung der Datenschicht austauschbar machen (sorry, wenn ich als Jurist und Teilzeit-Entwickler nicht immer die richtige IT-Terminologie treffe).

Ich musste mir mal ein größeres Geschäft durch die Lappen gehen lassen, weil ein Interessent zwar an meinem Adressprogramm sehr interessiert war, er wollte aber als Datenbank ein bestimmtes Format haben und SQL-Abfragen sollten möglich sein. Da musste ich leider passen.

Insofern wäre es Klasse, wenn man das Programm so umschreiben könnte, dass man die Daten von frei wählbaren Datenbank-Engines verwalten lassen könnte. Bei im Übrigen gleicher Oberfläche bzw. leichten Anpassungen an erweiterten Fähigkeiten der jeweiligen Datenbank-Engine.

Nun, da ich ja leider (noch) keine Ahnung von der klassischen Datenbankprogrammierung habe (also die Sachen, die Delphi so anbietet), meine Frage, ob es hierzu entweder Literatur oder Demo-Beispiele gibt, wo einmal demonstriert wird, wie man das von Dir beschriebene Modell implementiert?