Zitat:
b) und d) ist gleich nur die schreibweise ein wenig anderes
Nein eben nicht. Alle Methoden sind gleich bis auf d.)
Während alle Methoden langsam, dynamisch und fehlerträchtig sind ist die methode d.) über zur Designzeit angelegte Field-Komponenten übersichtlich, wesentlich schneller, typsicher und universeller.
Angenommen wir möchten ein DBGrid nutzen und ein Fließkomma Datenbankfeld extra formatieren und eine extra Konvertierung der Eingaben durchführen. Man legt dann zum DateSet alle Feldkomponenten an. Innerhalb dieser Feldkomponenten besteht nun die Möglichkeit über .DisplayFormat den Inhalt den Datenbankfeldes im DBGrid zu formatieren. Nun möchte man noch zusätzliche Konvertierungen berücksichtgen was ganz einfach über die Ereignisse der Fieldkomponente möglich ist. Dies geht ALLES nicht wenn man wie oben dynamisch auf die Felder einer
DB zugreift, bzw. es ist sinnlos dynamisch auf die Felder zuzugreifen wenn man schon Field Komponenten angelegt hat.
Zb. eine Tabelle enthält 50 Datenbankfelder. Wenn man wie oben dynamisch darauf zugreift so muß die
DB-
VCL per Stringvergleiche im Durchschnitt 25 Strings vergleichen -> nämlich die Feldnamen des gesuchten Feldes mit den Feldnamen in der
DB. Im obigen Falle wären also ca. 75 Stringsvergleiche bei 50 Datenfeldern nötig. Legt man aber zur Designzeit Feldkomponenten an und greift über .AsString zur Laufzeit auf deren Inhalte zu so stellt dies ein DIREKT Zugriff dar, also ohne Feldnamen's -Vergleichen.
Somit unterscheidet sich mein Vorschlag von allen anderen gravierend. Er ist NICHT die beste Lösung für dein Problem mit einer besseren Source-Formatierung, sondern er stellt DIE beste Lösung im gesammten dar, wenn man mit DataSets + Fields arbeiten will.
Gruß Hagen