Leitfaden für die Nutzung von FireDAC-Komponenten

[ioster]

Hallo zusammen,

ich bin immer noch auf der Suche nach einer vernünftigen Dokumentation der FireDAC-Komponenten. Ich nutze Delphi 10.3 Update 2 in Verbindung mit MS SQL Server und vor allem DevExpress-Komponenten.

Seit einem guten halben Jahr versuche ich, eine brauchbare Anwendung zu schreiben. Vom Advantage Database Server als Datenbank habe ich mich mittlerweile verabschiedet, weil die Komponenten meiner Version offenbar nicht so einwandfrei mit der neuesten Delphi-Version harmonierten.

Nun hatte ich einige Ungereimtheiten auf diese Inkompatibilität geschoben, doch ich komme auch mit dem MS SQL Server nicht wirklich weiter.

Das Grundproblem sehe ich bei den FireDAC-Komponenten, die eine Vielzahl von Einstellungsmöglichkeiten haben, deren Abhängigkeiten untereinander und die genauen Einflüsse auf das Verhalten der Datenbank nur begrenzt dokumentiert sind.

Beim Support vom Embarcadero habe ich inzwischen mehrfach nach einem Leitfaden gefragt, aber man verweist nur auf Samples und die Documentation. Wie sollen einem die weiterhelfen, wenn die Beispiele nicht den Praxisfall treffen.

Gibt es irgendwo etwas Vernünftiges möglichst auf Deutsch, das einem die Verfahrensweise der FireDAC-Komponenten erklärt und auf mögliche Risiken und Bugs hinweist? Dabei möchte ich noch einwerfen, dass ich mit den klassischen Methoden von Tables für die Bearbeitung von einzelnen Datensätzen arbeite. Queries setze ich vor allem für die Darstellung der Datensuche und der Auswertung ein.

Danke im Voraus.
Ingo

[Uwe Raabe]

Delphi in Depth: FireDAC

Alternativ auch in Papierform: Delphi in Depth: FireDAC

[ioster]

Danke für den Tipp. Das Buch habe ich mir als eBook-Version schon vorab gekauft und heruntergeladen. Bei meinen Problemen hilft es mir allerdings auch nicht wirklich weiter. Dort sind die Eigenschaften einer Connection aufgelistet und mit einfachen Beispielen geht es auch um Datenänderungen in Grids - die simplen Methoden wie Append, Edit und Post für eine Table sucht man jedoch vergeblich.

Gruß
Ingo

[Uwe Raabe]

Zitat:

Zitat von ioster (Beitrag 1451573)

die simplen Methoden wie Append, Edit und Post für eine Table sucht man jedoch vergeblich.

Die sind doch für alle TDataSet-Abkömmlinge identisch. Wo liegt denn genau dein Problem?

[ioster]

Das genaue Problem liegt beim Speichern und Aktualisieren der Daten. Ich kenne es so, dass mit einem Post die Daten in der Datenbank stehen. Wenn ich in meiner Anwendung Daten erfasse, dann sieht alles gut aus. Schaue ich nach dem Post in die Datenbank, dann fehlen aber die Feldinhalte.

Editiere ich eine Parametertabelle in meiner Anwendung über ein Grid und kehre in einen Stammdatendialog zurück, dann sind diese optionalen Werte nicht aktuell. Neue Einträge fehlen, geänderte Einträge sind noch so wie vorher. Nach einem Neustart der Anwendung stehen mir die Parameter so wie gewünscht zur Verfügung.

Ein weiteres Problem ist der Abruf der Daten. Ich habe letzt nach einigem Hin und Her den FireDAC-Monitor aktiviert. Mit dem Öffnen eines Stammdatendialogs setze ich die Table auf Active := true. Die Datenbank holt daraufhin alle Datensätze aus der Tabelle, was bei einem umfangreichen Adress- oder Artikelstamm sehr viel sein kann. Mit Änderung der RecsMax in den FetchOptions kam aber nichts Brauchbares mehr dabei heraus.

Insofern sehe ich den Ansatz bei den generellen Einstellungen der FDConnection. In dem Buch von Cary Jensen ist so ein Fall aus der Praxis nicht beschrieben. Die Beispiele zielen alle auf eine Bearbeitung per Grid ab und lassen solche Anwendungsprobleme wie ich sie habe außen vor.

Gruß
Ingo

[hhcm]

Zitat:

Zitat von ioster (Beitrag 1451582)

Editiere ich eine Parametertabelle in meiner Anwendung über ein Grid und kehre in einen Stammdatendialog zurück, dann sind diese optionalen Werte nicht aktuell. Neue Einträge fehlen, geänderte Einträge sind noch so wie vorher. Nach einem Neustart der Anwendung stehen mir die Parameter so wie gewünscht zur Verfügung.

Zurückkehren in ein geöffnetes Dataset? Wie wäre es mit einem Refresh? Oder Schließen und erneutes öffnen? Das ist kein Problem von FireDAC, das ist bei jedem DataSet gleich.

[ioster]

Wenn ich im Formclose die Datenquelle wieder schließe und beim erneuten Öffnen des Dialogs wieder aktiviere, dann sollte das mit einem Refresh gleichzusetzen sein. Das Programm greift nur eben nicht auf die aktualisierte Datenbank zu, sondern auf das, was beim ersten Mal geladen wurde. Und das ist ein wesentlicher Punkt, den ich nicht verstehe und der in der Anwendungsentwicklung fatal ist.

Gruß
Ingo

[hhcm]

Vielleicht query.CachedUpdates ?? Da hilft ein einfaches .Post nicht.

[Frickler]

Zitat:

Zitat von hhcm (Beitrag 1451587)

Vielleicht query.CachedUpdates ?? Da hilft ein einfaches .Post nicht.

Da muss dann nach dem .Post noch .ApplyUpdates kommen.

Es kommt drauf an, was FireDAC im Hintergrund mit Transaktionen anstellt. Wenn erstmal alle Insert/Update/Delete nur gesammelt und erst beim Schließen der Table committet werden, dann sieht man Änderungen nie sofort.

[hoika]

Hallo,

Zitat:

Das Programm greift nur eben nicht auf die aktualisierte Datenbank zu, sondern auf das, was beim ersten Mal geladen wurde.

Du redest jetzt von Mehrbenutzer-Modus (mehrere Rechner) oder ist es das gleiche Programm?
d.h. Fall1
- Programm.Exe wird gestartet
- macht eine Connection auf
- öffnet ein Formular, speichert dort die Daten ab, schließt das Formular
- öffnet ein anderes Formular und dort sind die Daten nicht zu sehen?

oder ist das Fall2
Rechner 1
- Programm.Exe wird gestartet
- macht eine Connection auf
Rechner 2
- Programm.Exe wird gestartet
- macht eine Connection auf

Rechner 1
- öffnet ein Formular, speichert dort die Daten ab, schließt das Formular
Rechner 2
- öffnet ein anderes Formular und dort sind die Daten nicht zu sehen?
- Programm.Exe wird gestartet
- macht eine Connection auf

[ioster]

Es muss doch aber irgendwo eine Einstellung geben, die die FireDAC-Connection/-Table dazu veranlasst, die Daten sofort zurückzuschreiben. Ich habe es gerade nochmal ausprobiert: ich erfasse referenzierende Daten in einem Quantumgrid und bin der Meinung alles ausgefüllt zu haben. Selbst wenn ich mit dem Navigator den Datensatz wechsel und wieder zurückblätter wird mir das vorgegaukelt.

In der Datenbank sind aber nicht alle Feldinhalte angekommen und nach dem nächsten Neustart sehe ich auch in der Anwendung das Problem. So kann man doch aber keine vernünftige Anwendung programmieren.

Von Refresh oder Commit ist nirgends in der Dokumentation von Embarcadero die Rede, wenn es um die Bearbeitung von Daten geht. Vielmehr habe ich letzt in einem anderen Zusammenhang den Hinweis auf Live-Daten gefunden, der mir vom Support aber auch nicht näher erläutert wurde. Ich möchte die Daten live haben, live in der Datenbank gespeichert und die aktuellen Daten aus der Datenbank live auf dem Schirm. So kenne ich das aus meiner langjährigen Programmierpraxis, wobei eben FireDAC vollkommen neu für mich ist. Um BDE konnte ich auch immer einen Bogen machen, weil ich mit Komponenten von Extended Systems/Sybase/SAP immer direkten Zugriff auf die Tabellen des Advantage Database Server hatte.

Die Logik der Tabellen sollte eigentlich bei allen Komponenten gleich sein. Deswegen sehe ich das Problem immer noch bei den Einstellungen der FireDAC-Schicht.

Viele Grüße
Ingo

[hoika]

Hallo,

Zitat:

ich erfasse referenzierende Daten in einem Quantumgrid

Aha, gut zu wissen.

Was sagt denn der DB-Monitor beim Wechsel des Records im Grid?
Ich würde jetzt eher mal beim Quantumgrid nachsehen.

[Uwe Raabe]

Um den Fehler in FireDAC zu verorten (oder auch nicht), würde ich eine beliebige simple Tabelle in der DB nehmen, ein TFDTable mit passender Connection auf ein Form setzen und mit einer Table.Open, Table.Edit, <Feld setzen>, Table.Post schauen, ob die Änderung in der DB ankommt. Solche Dinge mache sicher nicht nur ich zuhauf - erfolgreich.

[Delbor]

Hi zusammen

Was ist eigentlich der Vorteil/Unterschied der DB-Programmierung via FireDac-Objekten vs SQL?
Wollte ich eine DB mit Firedac programmieren, denke ich mir, dass die Lernkurve doch steiler ist.

Gruss
Delbor

[HeZa]

Zitat:

Zitat von Delbor (Beitrag 1451660)

Was ist eigentlich der Vorteil/Unterschied der DB-Programmierung via FireDac-Objekten vs SQL?
Wollte ich eine DB mit Firedac programmieren, denke ich mir, dass die Lernkurve doch steiler ist.

Hm..., ich programmier eigentlich immer mit FireDAC und SQL

[Delbor]

Hi HeZa

Zitat:

Zitat von HeZa (Beitrag 1451661)

Zitat:

Zitat von Delbor (Beitrag 1451660)

Was ist eigentlich der Vorteil/Unterschied der DB-Programmierung via FireDac-Objekten vs SQL?
Wollte ich eine DB mit Firedac programmieren, denke ich mir, dass die Lernkurve doch steiler ist.

Hm..., ich programmier eigentlich immer mit FireDAC und SQL

Ach ja, klar, ich auch. Ich hab mich da sehr undeutlich ausgedrückt. So arbeite ich nicht mit FireDac-Methoden wie zum Bleistift Append, sondern erledige sowas mit SQL.
Tabellen gebe ich auch nicht mit den entsprechenden Komponenten aus (DBGrid & Co), sondern per Query-Abfrage und befüllen eines Stringgrids.

Gruss
Delbor

[Frickler]

Zitat:

Zitat von Delbor (Beitrag 1451668)

Ich hab mich da sehr undeutlich ausgedrückt. So arbeite ich nicht mit FireDac-Methoden wie zum Bleistift Append, sondern erledige sowas mit SQL.
Tabellen gebe ich auch nicht mit den entsprechenden Komponenten aus (DBGrid & Co), sondern per Query-Abfrage und befüllen eines Stringgrids.

Für statische Datengitter sicherlich sinnvoll. Aber wenn Du in der Tabelle rumeditieren willst a la Excel, dann kommt ein DBGrid mit "Table"-Komponente Dir sehr entgegen. Drittkomponenten wie InfoPower oder Quantumgrid sind genau darauf ausgelegt mit Bergen an spezialisierten Feldeditoren.

[DasWolf]

Möchte man eine Connection, bei der die Fehlerquellen so gering sind wie möglich, dann sollte man die Finger von den Eigenschaften lassen.
Die Hilfe zu FireDAC ist nicht wirklich praktikabel. Da sind schon zum Teil sehr fragwürdige Beispiele drin.

FDConnection rein ins Formular oder Datenmodul, FDQuery oder FDTable dazu und voilà, es funktioniert.
Sollen Änderungen zwischengespeichert und am Ende der Bearbeitung zur Datenbank geschrieben werden, dann suche mal in der Hilfe nach

Delphi-Quellcode:

CachedUpdates

und

Delphi-Quellcode:

ApplyUpdates

.

[Uwe Raabe]

Zitat:

Zitat von Delbor (Beitrag 1451668)

So arbeite ich nicht mit FireDac-Methoden wie zum Bleistift Append, sondern erledige sowas mit SQL.

Ich habe mittlerweile schon mindestens drei solcher Projekte fast komplett auf die Standardmethoden (Append, Edit, Post, Delete) umschreiben müssen als sie auf Multi-Tier erweitert werden sollten. Bezeichnenderweise waren alle diese Projekte vorher bereits so aufgesetzt worden, dann aber irgendwann SQL-fiziert worden.

[ioster]

Hallo,

vielen Dank für die vielen Rückantworten und Anregungen! Ich komme mit dem Lesen gar nicht mehr nach. Es beruhigt mich aber schon ein wenig, dass ich technisch mit der Nutzung der FDTables und deren Methoden generell richtig liege und meine Einschätzung hinsichtlich der Dokumentation auch nicht falsch ist.

Die DevExpress-Komponenten als Verursacher meiner Phänomene hatte ich nach dem Desaster mit ADS bei der Fehlersuche hinten an gestellt. Wie gesagt, ich versuche mich ja erst einmal in die technischen Feinheiten der FireDAC-Komponenten reinzufuchsen. Der FireDAC-Monitor wirft mir viel zu viele Informationen aus, um damit etwas anfangen zu können. Kann ich das auf ein Minimum reduzieren, also nur die SELECT, UPDATE und DELETE-Befehle anzeigen lassen?

Ein Funktionstest der Anwendung hat mir gerade gezeigt, dass die Daten, die ich als erstes in einer Zelle von einem QuantumGrid eingebe, gespeichert werden. Alle nachfolgenden Eingaben verpuffen. Die Komponenten sind meines Wissens aktuell (Version 19.1.6). Dank Wartungsverträge bekommt man ja ständig Updates. Wenn das ein allgemeines Problem wäre, dann hätten da andere auch schon längst aufgemerkt.

Für mich ist immer noch das größte Problem, dass mir die Zeit wegen diese Datenbankgeschichten in der eigentlichen Programmierung davonläuft. In den letzten 20 Jahren habe ich nie so lange herumbasteln müssen, um eine saubere Datenbehandlung hinzubekommen. Das, was ich hier seit fast sechs Monaten erlebe, wird nur noch vom dem OCX-Gehassel getoppt, das ich mit Visual Basic vor Urzeiten hatte.

Ich werde wohl tatsächlich nochmal mit einem kleinen Testprojekt anfangen müssen, um den Verursacher ausfindig zu machen.

Viele Grüße
Ingo

[hoika]

Hallo,
noch was zum Lesen über das QuantumGrid ...

http://blog.nwoolls.com/2012/07/11/g...ssquantumgrid/

(Da gibt es auch noch alte Posts, viell. ist ja etwas dabei).

[ioster]

Moin,

ich habe inzwischen eine Fehlstellung in der fdConnection als Auslöser für Ungereimheiten ausmachen können.

In den UpdateOptions gibt es den Unterpunkt RefreshMode. Stellt man den auf rmManual, ist das von mir beschriebene Chaos perfekt. Ich habe anhand der dürftigen Beschreibung zusammengereimt, dass dieser Parameter zur Lösung meines Problems beitragen kann.

Ich muss dazu anmerken, dass ich diesen Wert nicht bewusst gesetzt habe. Vielmehr wird der Wert von der IDE umgesetzt, sobald man die Option FastUpdates aktiviert. Natürlich wird der Wert nicht automatisch zurückgesetzt.

Ein Phänomen konnte ich damit lösen, aber ich habe schon das nächste, was das Post der Masterdatenquelle betrifft. Sobald mir ein Forschungsergebnis vorliegt, publiziere ich das gerne, um anderen Betroffenen zu helfen.

Viele Grüße
Ingo

[ioster]

Falls bei jemandem im Zusammenhang mit FireDAC-Komponenten unter Delphi 10.3 ein EVariantTypeCaseError mit der Meldung "Variante des Typs (Null) konnte nicht in Typ (OleStr) konvertiert werden" auftritt, der sollte sein System auf Delphi 10.3.3. Ich musste mich natürlich mit der Meldung unter 10.3.2 herumärgern.

Viele Grüße
Ingo

[MEissing]

Zitat:

Zitat von ioster (Beitrag 1454578)

Moin,

ich habe inzwischen eine Fehlstellung in der fdConnection als Auslöser für Ungereimheiten ausmachen können.

In den UpdateOptions gibt es den Unterpunkt RefreshMode. Stellt man den auf rmManual, ist das von mir beschriebene Chaos perfekt. Ich habe anhand der dürftigen Beschreibung zusammengereimt, dass dieser Parameter zur Lösung meines Problems beitragen kann.

Ich muss dazu anmerken, dass ich diesen Wert nicht bewusst gesetzt habe. Vielmehr wird der Wert von der IDE umgesetzt, sobald man die Option FastUpdates aktiviert. Natürlich wird der Wert nicht automatisch zurückgesetzt.

Ein Phänomen konnte ich damit lösen, aber ich habe schon das nächste, was das Post der Masterdatenquelle betrifft. Sobald mir ein Forschungsergebnis vorliegt, publiziere ich das gerne, um anderen Betroffenen zu helfen.

Viele Grüße
Ingo

Steht doch genauso hier drin:
http://docwiki.embarcadero.com/Libra...ns.FastUpdates

Warum sollte das Setzen von FastUpdates auf False diese Einstellungen wieder rückgängig machen?

[ioster]

Zitat:

Zitat von MEissing (Beitrag 1455234)

Steht doch genauso hier drin:
http://docwiki.embarcadero.com/Libra...ns.FastUpdates

Warum sollte das Setzen von FastUpdates auf False diese Einstellungen wieder rückgängig machen?

In der Hilfe steht auch, dass es sich um einen "Kurzbefehl für das Setzen" von anderen Eigenschaften ist, d.h. FastUpdates ist für sich nur eine Geschichte, die in der IDE eine Auswirkung hat. Das, was bei mir über Wochen schiefgelaufen ist, ist auf die davon beeinflussten Eigenschaften zurückzuführen, die für den einen oder anderen vielleicht sinnvoll sind, doch dann kann er sich die auch alle einzeln so einstellen.

Meiner Ansicht nach ist das Risiko zu groß, wenn man die Eigenschaft FastUpdates versehentlich oder zum Ausprobieren auf True setzt. Ich habe die Eigenschaft jedenfalls nicht bewusst aktiviert und habe dadurch erheblichen Mehraufwand und Streß. Heute habe ich für ein Update auf Delphi 10.3.3 einen halben Tag aufgewendet. Immerhin sind damit auch Fehler in der FireDAC-Schicht bereinigt, die mit der 10.3.2 erst hineingekommen waren.

Wenn ich mir manchen Forenbeitrag im Zusammenhang mit FireDAC durchlese, fühle ich mich auch bestätigt, dass die Dokumentation unzureichend ist und in manchen Fällen auch Fehler aufweisen soll.

Viele Grüsse
Ingo

[hoika]

Hall,
warum ärgerst Du dich 3 Seiten lang über FireDac rum.
Bleib doch bei DevExpress.

Ausserdem tust Du dir keinen Gefallen bei der:
1. Nutzung der Table- statt der Query-Komponenten
2. Nutzung dastensensitive Elemente (ich nehme mal an, du benutzt TDBEdit und Konsorten)

Du hast mehr Aufwand, aber besseren Einfluss, z.B. auch auf Table.Open=alle Datensätze holen usw.

Der FireDAC-Monitor ist Gold wert, wie Du ja bereit gesehen hast.


Wir benutzen übrigens IBDAC (mit Firebird) und sind damit zufrieden.

[ioster]

Zitat:

Zitat von hoika (Beitrag 1455248)

Hall,
warum ärgerst Du dich 3 Seiten lang über FireDac rum.
Bleib doch bei DevExpress.

Ausserdem tust Du dir keinen Gefallen bei der:
1. Nutzung der Table- statt der Query-Komponenten
2. Nutzung dastensensitive Elemente (ich nehme mal an, du benutzt TDBEdit und Konsorten)

Du hast mehr Aufwand, aber besseren Einfluss, z.B. auch auf Table.Open=alle Datensätze holen usw.

Der FireDAC-Monitor ist Gold wert, wie Du ja bereit gesehen hast.


Wir benutzen übrigens IBDAC (mit Firebird) und sind damit zufrieden.

Da ich bis Anfang letzten Jahres nur mit einer wesentlich älteren Delphi-Version tagtäglich gearbeitet habe, wollte ich vor Beginn des neuen Projektes sichergehen, dass ich mit dem aktuellen Release vernünftig auf Datenbanken zugreifen kann. Es sprach vieles für FireDAC, weil damit geworben wird, man könne damit alle gängigen Datenbanken ansprechen.

Mit MyDAC und SDAC von DevArt als auch mit den Komponenten zum Advantage Database Server hatte ich gute Erfahrungen gemacht und konnte BDE gut umgehen. Es stand von DevExpress als Tzlieferer der visuellen Komponenten (z.B. QuantumGrid) im Raum, nur mit FireDAC problemlos zusammenzuarbeiten.

Inzwischen bin ich wirklich frustriert, was FireDAC betrifft, was nicht so schlimm wäre, wenn von dem Projekt nicht auch mein Einkommen abhängig wäre und ich es nur aus Jux und Dollerei machen würde. Das schlie0t sich alleine schon von den Lizenzkosten schon aus.

Viele Grüße
Ingo

[hoika]

Hallo,
ja, das ist ein Grund und sehr ärgerlich.
Wir benutzen ausschließlich Firebird (früher Interbase).
Am Anfang sogar noch mit der BDE, uiui.

Aber ich würde trotzdem zumindestens weg von datensensitiven Elementen
und TDataSet-(TTable-) Komponenten.
Das TTable ist kein Ersatz für eine TQuery.

[haentschman]

Moin...8-)

Zitat:

Bleib doch bei DevExpress.

...:lol: :zwinker:

Ich hatte letztens auch meinen Spaß mit FireDAC. Das hat mich komplett einen Tag gekostet...weil man die Meldungen nicht vernüftig liest. :evil:
PS: Altprojekt FDQuery auf der Form (mag ich eigentlich nicht :roll:)

Ich habe mir herausgenommen ein Datenbankfeld größer zu machen. Soweit so gut.
Ergebnis:

Zitat:

[FireDAC][Phys][ODBC]-345. Daten zu groß für Variable [IXADR]. Maximale Länge = [32], tatsächliche Länge = [46] Hinweis: Setzen Sie TFDParam.Size auf einen größeren Wert.

Hä? :gruebel:
Alle Felder kontrolliert. Alle Größen passen. Dann denke ich...ODBC? Wir haben nur den Native Treiber! Ins System geschaut...da war einer. :evil: Entfernt. Meldung war weg. :cheer: April, April. Den nächsten Tag hatte ich das wieder. :evil: Erneute Suche....
Lösung:
In der FireDAC Query gab es einen String Parameter. Der Parameter hatte eine Länge und zwar immer noch die Alte! :kotz:

Wer hat schon mal einem SQL Parameter eine Länge vergeben? Was ist der Sinn dahinter? :gruebel:
...again what learned. :stupid:

Danke für Zuhören...:wink: