Eher einfach. J/N in einem CHAR(1) Feld ist kein Boolean. So einfach ist. Die Interpretation passiert in der Applikation und nicht auf der
DB. Woher soll FireDAC wissen was ein Boolean sein soll, wenn es noch nicht mal die
DB weiß. Damit ist 'die' Defintion nicht da.
Morden ist es Ja/Nein, Yes/No, YES/NO, y/n, j/n, J/Nein, */o usw... in sämtliche andere Sprachen ist es auch anders. Es gibt eben nicht nur Deutsch ....
Wenn man das soll will dann kann man getrost einen Trigger machen und T/F abfangen. (eine Notlösung).
Entweder man schlieft den Wert durch und kümmert sich um die Enumeration selber oder eben man bildet den Boolean als SmallInt auf der
DB in der Domäne, denn FireDAC bildet True oder False an sich auf 0 oder 1 ab. Das ist eh schon die beste Annährung an die Realität in anderen DBs.
Die Notlösung das über
DB-Komponenten zu schleifen im Falle von Firebird hilft mal nicht viel. Die ist einfach falsch. Es handelt sich um eine konkrete Interpretation einer Domäne in der
DB als CHAR(1) mit 2 Werten auf der Anwendungsebene. M/W ist auch nicht boolean sondern ein Applikationsdomäne.
Wer eine Interpretationsschicht will braucht eine Interpretationsschicht. Das kann ein ORM sein, einfach Funktionen, ein Schema dazwischen, Bidnings oder eben Überbau unterhalb des Comp Layers.
Obwohl FireDAC im
SQL als Macro eher flexibel ist, gefällt mir persönlich der Zugang über den Weg nur sehr bedingt. Das ist sehr nützlich, würde aber einen Basisdatentyp so nicht als Sonderfall behandeln wollen.
Ich glaube ehrlich gesagt dass ihr mit eurem Display-Kram auf der falschen Spur seid.
Wir speichern hier auch J/N in der Datenbank. Was dann dem User angezeigt wird ist nochmal eine ganz andere Geschichte.
Und die Helper Funktionen sollen sein damit sowas geht:
Feld.AsString := BoolToJN(x > 3);
statt
Delphi-Quellcode:
if x > 3 then
Feld.AsString := 'J'
else
Feld.AsString := 'N';
Es sei denn wir reden alle komplett aneinander vorbei :/