TFDMemtable und ftvariant

[Ghostwalker]

Moinmoin und ein friedliches Weihnachten euch allen :)

Problembeschreibung:

Ich steh mal wieder vor dem Problem, Konfigurationsdaten zu speichern. Durch die letzte Coderage (en) bin ich auf TFDMemtable im FireDAC gestoßen und ich dachte mir mal, ja warum nicht mal ausprobieren.

Dabei will ich folgende Struktur verwenden:

cfgCatpath String (ftString)
cfgName String (ftString)
cfgValue Variant (ftVariant)

Soweit so gut, in der Componente die FieldDefs angegeben, und......mööök

Er meckert, das cfgValue einen unbekannten Datentyp hat und er das nicht handeln kann.


Die Frage:

Wie handelt man ftVariant ? Ich dachte eigentlich, das das letztlich so etwas wie der Variablentyp Variant ist und man letztlich beliebige Datentypen reinschieben kann.

Hoffe mal das mir da jemand weiterhelfen kann :)


Gruß

Uwe

[MichaelT]

Vergiss meine Antwort. War zu schnell geschossen.

[Uwe Raabe]

FireDAC behandelt ftVariant immer als unbekannten Datentyp. Kann man nachsehen in TFDFormatOptions.FieldDef2ColumnDef (FireDAC.Stan.Options.pas).

Ursache wird wohl sein, daß es nur wenige Datenbanken gibt, die mit so einem Feldtyp klar kommen würden.

[Ghostwalker]

Hmmm...schade. Das wär die Ideale Möglichkeit für Programmoptionen gewesen. :(

[Uwe Raabe]

Zitat:

Zitat von Ghostwalker (Beitrag 1422170)

Das wär die Ideale Möglichkeit für Programmoptionen gewesen.

Andernorts werden ja INI-Dateien für sowas verwendet. Dort wird am Ende alles auf Strings runtergebrochen. Einen ähnlichen Ansatz könntest du mit dem MemTable ja auch verfolgen.

[MichaelT]

Der 'Feldtyp' wird von ADO erkannt. Devart kann damit auch umgehen. Es stellt sich aber die Frage ob man im Fall von bspw. Datum eine Datum will oder ein OLE Datum zurückbekommt usw...

Düster, deswegen auch die Verwirrung zuvor, hatte ich mich erinnert, dass zu Zeiten von AnyDAC der Typ Verwirrung stiftete. Der Dmitry hat den Feldtyp glaube ich als Typ 'für alles andere' verwendet zu einer Zeit 'alles andere' noch überschaubar war. Will ihm jetzt nichts unterstellen, allein da ich mich nur düster erinnere.

Nicht in der MS Welt sondern bspw. auch in 4D gibt es einen Modus in dem der Datentyp selbst in der Datenbank nicht fixiert ist.

Die Speicherung von Programmoptionen mache ich mit einer Tabelle

Name für die Option | Typ | Wert als String

Damit war für mich das Thema relativ hurtig erledigt. Ala Windows Registry.

---

Alternativ kann man soviel ich weiß noch immer eine Structured Storage bemühen. Ist ein eigenes File (möglw. pro User) und kann man genauso in einer DB verräumen. Ein Kollege (lang, lang ist's her) von mir generiert aus Settings gespeichert in Betrieve diese Files und die liegen dann lokal bei der Applikation. In Delphi geht soviel ich weiß die OLE Variante. Ob ein Lösung mit nur In-memory Stream funktioniert muss man gucken.

Zitat:

Zitat von Ghostwalker (Beitrag 1422170)

Hmmm...schade. Das wär die Ideale Möglichkeit für Programmoptionen gewesen. :(