Leitfaden für die Nutzung von FireDAC-Komponenten

[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 von 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

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 von MEissing:

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 von 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.

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...

Zitat:

Bleib doch bei DevExpress.

...

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

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ä?
Alle Felder kontrolliert. Alle Größen passen. Dann denke ich...ODBC? Wir haben nur den Native Treiber! Ins System geschaut...da war einer. Entfernt. Meldung war weg. April, April. Den nächsten Tag hatte ich das wieder. 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!

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

Danke für Zuhören...