|
Datenbank: SQLite • Version: 3.x • Zugriff über: XE6 DBX
SQLite Treiber dbx Emba XE6 SP1 immer noch nicht zu gebrauchen
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 ? |
AW: SQLite Treiber dbx Emba XE6 SP1 immer noch nicht zu gebrauchen
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. |
AW: SQLite Treiber dbx Emba XE6 SP1 immer noch nicht zu gebrauchen
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
Habe ich mich auch etwas mit herumgeärgert, einen Timestamp immer als String zu bekommen. Aber so ist das doch in SQLite nunmal, oder? |
AW: SQLite Treiber dbx Emba XE6 SP1 immer noch nicht zu gebrauchen
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! |
AW: SQLite Treiber dbx Emba XE6 SP1 immer noch nicht zu gebrauchen
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. |
AW: SQLite Treiber dbx Emba XE6 SP1 immer noch nicht zu gebrauchen
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. |
AW: SQLite Treiber dbx Emba XE6 SP1 immer noch nicht zu gebrauchen
Zitat:
|
AW: SQLite Treiber dbx Emba XE6 SP1 immer noch nicht zu gebrauchen
Zitat:
Aber so wie du geschrieben hast kommen die Daten doch an (als WideMemo)... mit dem passenden DTO/Assembler kannst du das trotzdem dann verarbeiten ;) |
AW: SQLite Treiber dbx Emba XE6 SP1 immer noch nicht zu gebrauchen
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 |
AW: SQLite Treiber dbx Emba XE6 SP1 immer noch nicht zu gebrauchen
Zitat:
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? |
AW: SQLite Treiber dbx Emba XE6 SP1 immer noch nicht zu gebrauchen
Zusammen mit dem Schlagwort Delphi findet man dazu wenig bis nichts.
Ansonsten gibt es einige Quellen (C#, Java, etc.) die man aber adaptieren kann. |
AW: SQLite Treiber dbx Emba XE6 SP1 immer noch nicht zu gebrauchen
Ohne den Begriff "Delphi" und nur auf wenige Stichwort Deines Beitrags reduziert, finde ich z.B. das:
 http://www.mrknowing.com/2013/11/08/...n-architektur/Geht glaube ich in die richtige Richtung. |
AW: SQLite Treiber dbx Emba XE6 SP1 immer noch nicht zu gebrauchen
Zitat:
Da muss man bei jeder Schicht noch einmal in die Tiefe gehen. Beispiel GUI, da gibt es unterschiedliche Ansätze wie MVC, MVVM, ... wobei ich das MVVM besser finde, weil hier beim ViewModel schon der Schnitt von der GUI erfolgt. Bei MVC kennt der Controller noch die einzelnen Controls und bei Delphi ist somit der Controller auch vom Framework (VCL, FMX) abhängig und kann daher nur bedingt wiederverwendet werden. Ein ViewModel ist also nur eine Brücke zwischen der UI und dem Rest der Anwendung. Der Einstieg zum ViewModel mit Delphi wird auch nicht unbedingt leicht gemacht. Viele benötigte und hilfreiche Strukturen sind schon mal gar nicht vorhanden und müssen erst aufgebaut werden.
Auch das fehlende ARC für den Desktop-Bereich steht bei solchen Lösungen teilweise im Weg. (*) Spring4D lehnt sich ja sehr stark an Visual-C#/.Net an stolpert aber über den unbedingten Willen, das zu 100% Delphi-Event-kompatibel zu machen - was ich persönlich für überflüssig halte - und einige Stellen sind daher nicht mit nativem Delphi-Code zu realisieren wodurch die Portierbarkeit (Android, iOS, OSX) leidet. Bei .Net sind alle Events gleich aufgebaut mit einem Sender und einem EventArgument. Wenn man das genau so in Delphi umsetzt, dann braucht man das Gefrickel nicht und kommt mit reinem, portierbarem Delphi-Code klar. Die ObservableCollection in Spring4D feuert bei jeder einzelnen Änderung ein Event (z.B. eine Collection mit 1000 Items feuert bei Clear 1000 Events - eben so wie Delphi das eben macht) wo bei .Net genau ein Event gefeuert wird und beinhaltet u.a. eine Liste mit OldItems, die in diesem Fall eben diese 1000 Items enthalten. Wenn man das UI damit steuert, kann man sich schon ausrechnen, was da besser ist/wäre :roll: |
AW: SQLite Treiber dbx Emba XE6 SP1 immer noch nicht zu gebrauchen
Vielen Dank für Deine ergänzende Information. Da sind wieder eine Reihe von Stichworten dabei, womit man sich der Sache weiter nähern kann.:-D
Diese Art der gehobenen Software-Architektur wäre ja eigentlich auch ein schönes Thema für die Delphi-Tage gewesen... |
AW: SQLite Treiber dbx Emba XE6 SP1 immer noch nicht zu gebrauchen
Ein interessanter Artikel zu MVVM (nicht an .Net oder WPF stören) ist
hier. Nicht zu kompliziert aber auch nicht zu flach (wie die meisten Beispiele) |
AW: SQLite Treiber dbx Emba XE6 SP1 immer noch nicht zu gebrauchen
Zu Zeiten von BTRIEVE (Record Server) hat man die binäre Repräsentation eines Record in eine Datenbank abgelegt. Man hat an sich noch mitgegeben wie Character mit Code Pages zu interpretieren waren (Sortierung usw...).
Relationale SQL Datenbanken sind von der API her konzipiert für 4GL. SQL war zu Beginn eine Art Export Facility. Im Prinzip ein klassisches Provisorium. Und wie üblich in der IT hat man drüber gebaut. Es war für Unternehmen eine Befreiung, sie waren nicht mehr vom File Format von Anwendungen und programmierter Zugriffsprogrammen abhängig. Ich kenne noch ITs die haben Listen programmiert in C. So machen IT Leiter nicht heruntergestiegen und auch nicht Produkthersteller. Sichert das Businessmodell des einzelnen Hersteller oder Orgeinheit... Warum glaubst du gibt es soviele Fileformate. Die IT's konnten mit relationalen Datenbanken ihre eigenen Daten auslesen, aufbereiten usw... Es gibt an sich ein paar Standards. Dann gab es mal ANSI SQL. Diese Standards wurden implementiert und gleichzeitig haben die Datenbankhersteller auch aus durchaus ehrbaren Motiven Programmiersprachen eingebaut in die DBs... damit haben sie den Kunden anders eingefangen. Die sind geliefert in der Praxis. Es gäbe einen Prozeduralen Stand für DBs - der kam zu spät und kann nicht viel. Die Mimer hat den relativ exakt implementiert. - Alles nur DB. Jetzt hat man 2 Arten von Zugriff. Query - Abfrage und im Prinzip das Ausführen einer Prozedur und Übernahme des Ergebnisses das wiederum eine oder mehrere Tabellenstrukturen sein können. Etwas frei formuliert - explizite und implizite Cursor. Ist das verpackt in einer zumeist in C implementierten library dann spricht man von einem Treiber. ODBC ist ein gelungener Versuch ein normierten Datenbanktreiber zumindest aus Sicht der Anwendung respektive des Programmieres anzubieten. Einige Unterschiede verbleiben, ob des gemeinsamen Nenners. BDE und DB auf Treiber Ebene sind ähnlich gelagert. DBX wurde von Borland nicht weiterentwickelt. Die Treiber selbst waren an sich gut und das Konzept ansprechend. Die Komponentenseite war nichts ganz sauber. Nach einigen Versuchen im Guten Borland davon zu überzeugen die Komponentenseite zu verbessern hat dann ursprünglich ein Schweizer Unternehmen ihre OffShore (Dmitry Arefiev damals der Treiber hinter dem Ganzen) AnyDAC heute FireDAC geschrieben. Am Anfang wollte man Oracle direkt (NCOCI Ablöse), ODBC (Alternativ OLEDB, das wurde aber verworfen) und DBX unterstützen. Das hat so lala funktioniert, aber die Lösung war eben dann der Umweg über eine eigene SQL Ebene die auf SQL umgesetzt wird, das die Datenbank versteht. Diese normierende Schicht hat auch UNIDAC. Die Komponentenebne (TDataset Compatibility) frisst 40% der Speed. n-tier. Heißt nichts anderes als die Anzahl von RPC Indirektionen beginnend mit 1. pro Indirektion kommt eine dazu. Der Client Server Zugang (zumeist der Client spricht dem Server über eine eigens Protokoll. Das geht von einfach DEC RPC, IBM CPI-C in gewisser weise, SAP RPC, SAP GUI Protokoll, OCI, SQL PLUS Protokoll usw.. Das sind die 2 Tier Ansätze. Die haben alle eines gemeinsam. Der Client bekommt einen Bytestream und muss den mit bekannter Metainformation (Datensatzaufbau, Characterset usw...) interpretieren sodass mein Funktionsaufruf aus der 3GL Sprache (C, Pascal usw...) etwas verarbeitbares rauskommt. Im Prinzip wurden dann Elemente eingeführt die RPCs in Empfang nehmen (Proxies, Datasnap, ... usw...). Die Apptier war am Anfang eher eine Pooling Ebene die einfach die DB Sessions sollte entlasten. Klassiker ist (MTS von Microsoft). Der SQL hat in 60 keine 10 User geschafft ... Das war schon ein Schitt in Richtung 3Tier. Klassische 3 Tier ist Java und .net Remoting. Davon losgelöst hat sich CORBA als objektorientierter Zugang stark lastig im Sinne von OO rausgebildet eben noch begrenzt durch die Möglichkeiten des RPC. Das war eine verbesserter RPC zu Beginn. Ein anderer Ansatz sind Appserver - BEA (Objekt Proxies). Java hat damals einfach gewonnen da die Serialisierung weitaus einfach ging als in C/C++ mal ganz zu schweigen davon, dass man mit CORBA Librares RECORDS hat dynamisch zusammengebastelt. Der DB Access war so langsam dass man hergegangen ist und in der Not Java Objekt Repräsentationen hat gepoolt und das hat in der damaligen Zeit die Smalltalk und OO Typen nachdem sie mit OO Database grandios gescheitert waren sehr gut ins Konzept gepasst (ORM und Persistenzcontainer in die Java Appserver). Die Synthese von Dingen die nie funktioniert haben. Die 3 Tier wurde eingeführt damit man eben noch eine zusätzliche Protokollabstraktion reinbekommt. An sich wäre es so dass die Objekte auf der Apptier genauso lebten und am GUI nur angezeigt werden. Egal wie man technisch Realisiert. Web ist kein reiner 3 Tier in klassichen Definition. Ein HTTP Request ist eine andere Abstraktionsebene als der traditionelle RPC. In dem Sinne ist HTTP ein alternatives Protokoll zum RPC aber doch ein wenig mehr. Protokolle sind beide. Jetzt kommt die Gretchenfrage. Erzeugst du dir ein Objektlayer. Ich generiere mir auch einen. Eines darf man nicht vergessen. Eine Select Statement erzeugt zur Laufzeit Typen ... der Typ im Programm ist statischen (Impedance Missmatch). An sich für eine Applikationsperistenz Objekte ja und im schlimmsten Fall Collections aufbauen. Wenn das Ziel der Datenbank in kombinierbare Informationsbasis ist, dann Vorsicht. Objekte sind aus der Sicht zugreifenden Applikation eine Wahrheit die gegen das Informationsmodell beim DML geprüft wird oder alternativ in der TDataset Welt... Zitat:
|
AW: SQLite Treiber dbx Emba XE6 SP1 immer noch nicht zu gebrauchen
Zitat:
|
AW: SQLite Treiber dbx Emba XE6 SP1 immer noch nicht zu gebrauchen
wenn es dir nicht so unter den Nägeln brennt: Nick Hodges wird am 19.8. in den "Developer Skill Sprints Webinars" in Delphi ein MVVM in 20 Minuten erläutern:
http://forms.embarcadero.com/Develop...01G0000000tKTxTeilnahme kostenlos. Und dass es zum Thema ORM/GUI Anbindung und Delphi "wenig bis nichts" gibt ist so nicht richtig: Das Zeug versteckt sich leider nur sehr gut :-) Für die reine Datenbankanbindung würde ich eines der aktiven ORMs verwenden (DORM, tiOPF, InstantObjects oder Kaufware von Devart oder TMS) - bzw, wenn es denn sein muss eines selbst aufbauen (wobei man den Aufwand nicht unterschätzen darf). Für die Oberflächenanbindung habe ich bisher das MGM-Pattern (Model-Gui-Mediator) verwendet, bin aber schon sehr gespannt auf den MVVM Vortrag von Nick.... |
AW: SQLite Treiber dbx Emba XE6 SP1 immer noch nicht zu gebrauchen
Danke für den Webinar-Tipp. Werde zu den genannten Tageszeiten eher nicht können, aber vielleicht gibt es das ja später noch zum Download.
Habe von Malcom Groves ein interessantes Video zu MVVM mit gefunden: https://www.youtube.com/watch?v=Ci1HP8ZBJxkWenn man übrigens nach MVVM (und Delphi) sucht, findet man das eine oder andere auch hier in der DP und im Netz. |
AW: SQLite Treiber dbx Emba XE6 SP1 immer noch nicht zu gebrauchen
Zitat:
Für die Bearbeitung eines Datensatzes in einem Modal-Dialog braucht man kein MVVM und wenn man dann von dem gezeigten Beispiel ausgehend weiter machen will (kann doch nicht so schwer sein, geht doch, hatta ja gezeigt) dann werden die Gesichter immer länger. Wie gesagt, für diese PillePalle-Schmalspur-Augenwischerei reicht es, für eine Anwendung nicht. Schau dir die "simple" Anwendung von der MS-Seite an, die auch relativ flach ist, im Vergleich zu dem was MG da zeigt, sind das aber die Alpen. |
AW: SQLite Treiber dbx Emba XE6 SP1 immer noch nicht zu gebrauchen
Ja, wirst Du wahrscheinlich Recht haben. Mir ging es aber erst mal um den Einstieg und dafür erschien es mir ganz brauchbar...
|
AW: SQLite Treiber dbx Emba XE6 SP1 immer noch nicht zu gebrauchen
Zitat:
Schau dir erst das MS Beispiel an und wenn du das verstanden hast, dann schau dir nochmal das Video an und du wirst meine Antwort verstehen. Das Video führt leider in die falsche Richtung. |
AW: SQLite Treiber dbx Emba XE6 SP1 immer noch nicht zu gebrauchen
Zitat:
irgendwie hab ich mich beim PDT-Zeit umrechnen vertan und das Ganze glaub ich gerade verpasst. Hätte es sich gelohnt? Oder würde es sich lohnen es in der Nacht nochmal zu versuchen, wenn's denn mit dem Umrechnen klappt? |
AW: SQLite Treiber dbx Emba XE6 SP1 immer noch nicht zu gebrauchen
Es wird hoffentlich wieder Aufzeichnungen geben
|
AW: SQLite Treiber dbx Emba XE6 SP1 immer noch nicht zu gebrauchen
Zitat:
youtube-Kanal veröffentlicht - kann halt ein paar Tage dauern. |
AW: SQLite Treiber dbx Emba XE6 SP1 immer noch nicht zu gebrauchen
Liste der Anhänge anzeigen (Anzahl: 1)
So, das Webinar habe ich mir angesehen. Fand ich ganz hilfreich. Wird demnächst auch zur späteren Ansicht veröffentlicht.
Es wurde ein Link zum Download des Demoprojekts angegeben, da lande ich auf dieser Seite, wie im anliegenden Screenshot dargestellt. Bloß, wie lade ich den Source-Code jetzt runter? Bei Rechtsklick auf unterschiedliche Dateien, Ziel speichern unter, wird immer ein und dieselbe Datei runter geladen. In der Versionskontrolle öffnen funktioniert nicht. Was mach ich falsch? |
AW: SQLite Treiber dbx Emba XE6 SP1 immer noch nicht zu gebrauchen
Ja sowas hatte ich erwartet. So wirklich viel Fleisch ist da nicht dran und ein grundsätzlicher Designfehler ist dort auch noch drin.
Die View erzeugt das ViewModel und das erzeugt das Model. Super, das nenne ich doch mal flexibel und hilfreich. Ich dachte immer, das ViewModel bekommt das Model zugewiesen und die View das ViewModel. Gut für eine Ein-Fenster-Anwendung reicht das bestimmt, aber brauche ich da das MVVM-Pattern? Für mehr ist dieser Ansatz aber auch nicht zu gebrauchen. Da klebt der Nick noch zu sehr in der RAD-Gedankenwelt. |
AW: SQLite Treiber dbx Emba XE6 SP1 immer noch nicht zu gebrauchen
Zitat:
Für Cross-Platform wäre es auch bei einer Ein-Fenster-Anwendung schon gut, so ein Modell einzusetzen, dann ich kann dann ViewModel und das Model weiterverwenden und brauche nur die View auszutauschen. Den Link, den Du hier mal gepostet hattest ( http://msdn.microsoft.com/de-de/magazine/dd419663.aspx) zu einem MVVM-Artikel: Da fand ich die Einleitung als Einstieg sehr gut, das Demo mit C#-Quellcode war für mich (keine näheren C-Kenntnisse) aber leider nicht so gut zugänglich.Übrigens, was ich ein wenig schade finde: Potentiell an MVVM interessierte Entwickler werden unter diesem Thread-Titel hier (SQL-Treiber-Probleme) wohl kaum hier rein schauen. Kann man so einen Teil eigentlich hier irgendwie abtrennen und dann unter neuem Titel (z.B. MVVM-Softwarearchitektur in Delphi anwenden) oder ähnlich, fortsetzen? |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 20:26 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz