![]() |
AW: Leitfaden für die Nutzung von FireDAC-Komponenten
Hallo,
noch was zum Lesen über das QuantumGrid ... ![]() (Da gibt es auch noch alte Posts, viell. ist ja etwas dabei). |
AW: Leitfaden für die Nutzung von FireDAC-Komponenten
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 |
AW: Leitfaden für die Nutzung von FireDAC-Komponenten
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 |
AW: Leitfaden für die Nutzung von FireDAC-Komponenten
Zitat:
![]() Warum sollte das Setzen von FastUpdates auf False diese Einstellungen wieder rückgängig machen? |
AW: Leitfaden für die Nutzung von FireDAC-Komponenten
Zitat:
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 |
AW: Leitfaden für die Nutzung von FireDAC-Komponenten
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. |
AW: Leitfaden für die Nutzung von FireDAC-Komponenten
Zitat:
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 |
AW: Leitfaden für die Nutzung von FireDAC-Komponenten
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. |
AW: Leitfaden für die Nutzung von FireDAC-Komponenten
Moin...8-)
Zitat:
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:
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: |
Alle Zeitangaben in WEZ +1. Es ist jetzt 15:36 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