[FMX] FDQuery.FieldByName leifert falschen String

[TigerLilly]

Open/Close und Active sind gleichwertig. Auch die TFDQuery routet das Open auf Active:=True um.

[Schokohase]

Zitat von p80286:

Ich pers. würde Anmerkungen von Markus immmer sehr ernst nehmen. Aber das ist meine ganz pers. Ansicht.

Da wir aber alle Menschen sind und darum systembedingt auch Fehler machen können, ist es wichtig jede Aussage oder Anmerkung auch kritisch zu betrachten und auf Fehler hinzuweisen.

Eine unterwürfige und demütige Haltung ist hier völlig fehl am Platz und hilft niemandem.

Von daher hat @TigerLilly alles richtig gemacht.

[jobo]

Zitat von Hobbycoder:

..Ursache.
..
Mit ausreicht Kenntnisse über SQLite hätte ich es vielleicht wissen können, aber man kann tatsächlich einen Feldtyp von Text in Real ändern (in diesem Fall ist das versehendlich passiert), und alle Textwerte belieben in der Tabellenspalte vollständig erhalten. Und leider ist mein DB-Viewer so, dass er prompt den Textinhalt anzeigt.
FireDAC aber aufgrund des Fehdtypes konsequent 0 zurückliefert.

Wie gesagt, auf Grund der Tatsache, dass hinter SQLite keine DB-Server steckt, hätte ich auch eher drauf kommen können.

Das hat nichts mit DB-Server oder nicht zu tun. MS Access oder ähnliche Vertreter verhalten sich da nicht wie SQLite, sondern 'wie gewohnt'.
SQLite macht es einfach anders, mit dynamischen Typen, und hat es auch dokumentiert:

Zitat:

.. However, the dynamic typing in SQLite allows it to do things which are not possible in traditional rigidly typed databases.

https://www.sqlite.org/datatype3.html

"..Dinge, die in traditionellen System nicht möglich sind.."
Dazu gehören natürlich auch ungewöhnliche Fehlerkonstellationen.

Es gibt hier schon einige Threads, die auf diesem unerwarteten Verhalten beruhen, also den Auswirkungen dieses dynamic typing. Wenn man mit SQLite arbeitet und im weitesten Sinne Probleme Wertzuweisung und Rückgabe/Darstellung/Abfrage hat, sollte man spätestens an diese Besonderheit denken.

"Lustig", dass gerade in Delph respektive Pascal mit der exakten Typen Ideologie auch diese Schieflage auftritt. Was nochmal im Kontrast dazu steht, dass selbst unter "Delphianern" offenbar intuitiv gern Datumswerte als Text/String bearbeitet werden, um dann mit den Folgen zu kämpfen. Nagut, das ist der "Blinde Fleck" in der Datentypenbrille.

Dynamic Typing von SQLite ist dagegen einfach ein vollkommen ungewohntes "Feature". Ohne die Kenntnis oder Idee seiner Existenz ist es einfach tückisch, besonders in Kombination mit einer irrtümlichen Spaltentypisierung.

[Rollo62]

Zitat von TigerLilly:

Open/Close und Active sind gleichwertig. Auch die TFDQuery routet das Open auf Active:=True um.

Ich vermute mal das kommt daher das die DB-Komponenten gerne mal Active True/False auch im Designer anbieten.
Deshalb macht es wohl Sinn 2 gleichwertige Wege anzubieten, das macht durchaus Sinn.

[jobo]

An der gezeigten Implementierung kann man nur erkennen, dass "Open" zumindest in der Theorie mehr ist. Besser oder schlechter oder anders wäre vielleicht eine Spekulation auf die Zukunft, in der die Open Methode noch weitere Zeilen enthalten könnte, neben active := true.

Ich könnte mir auch vorstellen, dass die Problematik irgendwie mit

Code:

If dataset.active = true ..

vermischt wird, was jedenfalls nicht so ratsam ist.

Im Sinne von Klarheit und Lesbarkeit stellen Open für Datenmengen und ein Execute für Befehle für mich auch die bessere Alternative dar.

[Schokohase]

Solange wie die Eigenschaft Active anzeigt ob die Verbindung aktiv ist (oder eben nicht) und diese Eigenschaft nicht read-only ist, solange wird diese das Gleiche auslösen müssen, wie ein Aufruf von Open , wo die Verbindung geöffnet und damit aktiv wird, was dann durch die Eigenschaft Active entsprechend angezeigt wird.

[DasWolf]

Ich gehe mal davon aus, dass ein Standard angeboten wird.
Bei FDQuery1.Open gibt es ja noch die Möglichkeit, einen SQL-String anzugeben (mit oder ohne Parameter) FDQuery1.Open('SELECT ID, Bezeichnung FROM Tabelle1 WHERE ID = :ID', [1], [ftInteger]); .
Wahrscheinlich gibt es deshalb zusätzlich den Standard Open; um den Code einheitlich gestalten zu können.