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