FireDAC erkennt Boolean schreibt jedoch T/F anstelle von J/N

[Kostas]

Hallo zusammen,

ich habe in einer Firebird DB ein Feld vom Typ char(1) angelegt mit einem Check
J/N. FireDAC möchte unbedingt ein T/F schrieben. Wie kann ich das bitte unterbinden ohne dass ich ExtendedMetadata ausschalten muss?

Code:

CREATE DOMAIN AS_BOOL AS
CHAR(1) CHARACTER SET ISO8859_1
DEFAULT 'N'
NOT NULL
CHECK (VALUE IN ('J','N'))
COLLATE ISO8859_1;

Gruß Kostas

[Sherlock]

Kannst Du der jeweiligen Komponente nicht den Value für True bzw. False mitgeben?

Sherlock

[haentschman]

Moin...8-)

wäre 0/1 als SmallInt (Firebird) nicht eleganter weil eindeutiger? Nach Boolean casten ist erst Recht nicht problematisch.

[Kostas]

Zitat:

Zitat von Sherlock (Beitrag 1278526)

Kannst Du der jeweiligen Komponente nicht den Value für True bzw. False mitgeben?

Sherlock

Ja, ich übergebe True/False und FireDAC versucht T/F zu schrieben. Das geht
jedoch nicht weil ein Contraint (J/N) das verhindert. Ich möchte unbedingt
J/N schreiben denn es handelt sich um eine Anwendung die umgeschrieben wird
von Delphi 5 mit IBObjects auf Delphi XE7 mit FireDAC.
Das wird doch gehen zu bestimmen was true und false ist oder?

Gruß Kostas

[Kostas]

Zitat:

Zitat von haentschman (Beitrag 1278527)

Moin...8-)

wäre 0/1 als SmallInt (Firebird) nicht eleganter weil eindeutiger? Nach Boolean casten ist erst Recht nicht problematisch.

Nein kann ich nicht. Ich habe auch weitere Boolean Felder in denen M/W
steht für Männlich/Weiblich In diesem Fall soll im Grid in der Zelle M
oder W stehen und nicht T oder F oder 1 bzw. 0

Gruß Kostas

[DeddyH]

Mir scheint, Du vermischst Daten und Darstellung. Ich kenne FireDAC nicht, aber dort gibt es doch bestimmt auch so etwas wie DisplayValues, oder?

[user0815]

Zitat:

wäre 0/1 als SmallInt (Firebird) nicht eleganter weil eindeutiger?

würde ich machen

http://www.firebirdsql.org/refdocs/l...pd15-case.html
und die Daten so ausgeben...

[Kostas]

Hallo zusammen,

grundsätzlich möchte ich ExtendedMetadata verwenden wegen AutoInc u.s.w.
Ich könnte sicherlich eine Domain anlegen die nicht im Namen BOOL enthält
dann würde das Feld als String erkannt. Jetzt wird es als Boolean erkannt
und ich suche eine Möglichkeit bestimmen zu können wenn ich im DBCheckBox
anhacke der von mir bestimmte Wert in die DB geschrieben wird. Warum soll
ich 0,1 oder T,F schrieben und nicht True=Ja und False=Nein. Firebird kann
es und die IBO-Komponenten können das auch. Da kann ich für jedes Feld
Festlegen was der True Wert und was der False Wert ist.

Verstehe ich das jetzt richtig dass FireDAC mich hier beschneiden auf 0,1 bzw
T,F?

[Uwe Raabe]

Mangels reproduzierbarem Testfall kann ich auch nur raten, aber eventuell kannst du was mit den MapRules machen.

[p80286]

Zitat:

Zitat von Kostas (Beitrag 1278525)

Code:

CREATE DOMAIN AS_BOOL AS
CHAR(1) CHARACTER SET ISO8859_1
DEFAULT 'N'
NOT NULL
CHECK (VALUE IN ('J','N'))
COLLATE ISO8859_1;

Boolsche Werte als J/N zu speichern halte ich für grenzwertig

Zitat:

Zitat von DeddyH (Beitrag 1278530)

Mir scheint, Du vermischst Daten und Darstellung.

Ich denke Detlef ist hier auf der richtigen Spur.

Gruß
K-H

[Lemmy]

Zitat:

Zitat von Kostas (Beitrag 1278525)

Wie kann ich das bitte unterbinden ohne dass ich ExtendedMetadata ausschalten muss?

wo schaltet man ExtendedMetadata ein/aus?

Wo zeigst Du den Boolean denn an (Checkbox,..)?

[Kostas]

Hallo zusammen,

wenn FireDAC nur Integer als Boolean umsetzten würde, würde ich das Verhalten
zähneknirschend akzeptieren. Es überrascht mich doch sehr dass FireDAC für
Boolean ein T/F in das Feld schreiben kann, jedoch keine Einstellung zur
Verfügung stellt aus T/F ein J/N oder was auch immer einzustellen.
Wie gesagt, IBO hat das vorgesehen wie so vieles.

@Lemmi,
Ich habe eine DB aus einem vorhandene Projekt. Die DB habe ich kopiert und
versuche Form für Form umzustellen von Delphi5 und IBO auf DelphiXE7 und FireDAC. Es kommt eine Menge Frust hoch weil die einfachsten Dinge nicht gehen. Aktuell geht es um eine einfache Form auf dieser das Grid von DevExpress platziert ist. In der Connection.Parameter gibt es eine Einstellung
um ExtendedMetadata zu aktivieren. Wenn das aktiv ist, wir die Domain AS_Bool
als Boolean interpretiert. Das Grid zeigt danach auch automatisch eine
Checkbox an. Wenn ich die Checkbox einchecke wird versucht in das Feld
ein T zu schreiben.


Gruß Kostas

[tsteinmaurer]

Hallo Kostas,

ich kenne FireDAC (AnyDAC) viel zu wenig, um dir hier konkret weiterhelfen zu können, aber bei einem Austausch einer so zentralen Komponente wie die Datenzugriffsschicht, muss man doch auf einiges gefasst sein. Bei IBO sind es halt oftmals Feinheiten, die den Unterschied zu anderen Komponenten ausmachen. Mit der Boolean-Sache hast bereits eine gefunden, sofern FireDAC hier wirklich nichts anbietet, die in der Umstellung einer Legacy Anwendung sehr unangenehm werden kann und wird. Will hier jetzt nicht auf deine deutschsprachige Speicherung via J/N näher eingehen. D.h. sollte FireDAC hier nichts benutzerdefiniertes anbieten, dann wirst du vermutlich den Constraint abändern und im selben Atemzug alle Feldinhalte entsprechend updaten müssen.

Die Sache mit dem Boolean ist eine Feinheit. Etwas gröber wirds dann wenn man sich in IBO auf Sachen wie automatisches OIT/OAT Advancing verlassen hat. Von Features wie DML Caching zur Benachrichtigung bei Datenänderungen uvw. rede ich noch gar nicht. Weiss nicht ob FireDAC getrennte Transaktionen für SELECT und DELETE/INSERT/UPDATE unterstützt. So kann man z.b. für Selects eine Transaktion mit READ COMMITTED + READONLY verwenden, die auch bei langlaufenden Transaktionen keinen Performanceschaden anrichtet. Vermutlich wird FireDAC diese Trennung auch haben. In IBO steckt halt sehr, sehr viele Mannjahre an InterBase/Firebird-spezifischem KnowHow drinnen.

Will hier nicht notwendigerweise eine Lanze für IBO brechen, da ich z.b. auch IBDAC im Einsatz habe, aber ich befürchte dein Frustpotential wird noch (lange) nicht ausgeschöpft sein.

LG

[Kostas]

Hallo Thomas,

ich versuche herauszufinden ob ich die nativen IBO Komponenten ersetzen kann. Ich habe bis jetzt nur die nativen Komponenten eingesetzt. Ein paar Sachen gibt es da schon die mir nicht gefallen. Die Version 5 ist in ein paar Punkten problematisch. So z.b. wenn in ein TIB_Grid ein TIB_ComboBox integriert wird, wird das Control nicht wie erwarten innerhalb der Zelle gezeichnet sondern links oben im Bildschirmrand. Jason kann das nicht nachvollziehen.
Ein fehlverhalten das seit etwa 3-4 Monaten da ist. Jason hat von mit eine Test-Anwendung bekommen und auch ein Screen Capture Video. Doch bis Heute keine Reaktion. Die aktuelle Version kann ich nicht testen da ich die Lizenz habe ablaufen lassen. Was auch ziemlich nervt ist, wenn im TIB_Grid irgend welche IB_Controls platziert werden und man tippt die Zelle an, bekommt das Control nicht gleich den Focus, sondern erst nach dem dritten Click. Übrigens, TMS hat das gleiche Problem. DevExpress hat das Problem nicht!

Das Hauptproblem ist natürlich das die nativen Komponenten um so viel Produktiver sind als die DataSet kompatiblen IBO Komponenten, leider mit dem Nachteil dass man keine Drittanbieterkomponenten verwenden kann eben weil sie nicht DataSet kompatibel sind.

Meine Datenbank ist und bleibt Firebird. Eigentlich müsste ich bei IBO bleiben wegen der Produktivität. Doch die nativen Controls werden auch nicht aktualisiert habe ich das Gefühl. Somit bleibt die Optik
ziemlich hinten. Jason hätte eine DataSource entwickeln sollen das beides unterstützt native und DataSet.

Alleine schon der SQL Editor ist so produktiv, der neben den Editor auch eine Liste der Tabellen liefert und darunter die Liste der Feldnamen der aktiven Tabelle. Per doppenklick ist die Tabelle im Join und per Doppelklick ist das Feld im Select. Wenn man permanent damit zu tun hat, ist das maximal produktiv. In DBX, FireDAC und UniDAC fehlt das. Ein nackter Editor. Vermutlich bin ich der einzige Depp der sich die hunderte Tabelennamen und dessen Felder nicht merken kann. Jedes mal raus aus der IDE rein in IBExpert select erstellen und wieder zurück in der IDE um das SQL zu platzieren. Das kann es doch nicht sein.

Mal sehen was sonst noch ans Tageslicht kommt wenn ich weiter teste.

Sorry, für meine Ausdrucksweise... :-|

Schöne Grüße,
Kostas

[Lemmy]

Zitat:

Zitat von Kostas (Beitrag 1278592)

@Lemmi,
... Aktuell geht es um eine einfache Form auf dieser das Grid von DevExpress platziert ist.

DevExpress kenne ich nicht, aber viele andere hier. Bei den "normalen" DBCheckboxen kannst Du die Werte direkt bei der Komponente einstellen. Schau mal nach ob bei den DevExpress DBCheckboxen vergleichbare Einstellungen da sind, dann schau wie du das im Grid einstellen kannst...

Sorry, IBO sind da halt sehr speziell.

[Kostas]

Morgen Lemmy,

DevExpress hat die Einstellungen doch die werden ignoriert.
Ich sehe keine andere Möglichkeit als das Feld als Integer umzubauen. Es ist auch nicht wirklich
ein Problem, doch ärgerlich ist es schon.

Gruß Kostas

[TRomano]

Hallo Kostas,

ich bin mal kurz über diesen Thread geflogen und ich glaube, dass Du vielleicht ein kleines Problem hast: mit der vorgeschlagenen Domain Boolean als Integer-Wert kommt man sehr wohl klar. Es gibt halt nur die Entscheidung TRUE/FALSE. Dein Beispiel mit dem geschlecht ist etwas ganz anderes, nämlich ein Lookup-Field mit den Items "Mann,Frau,Transsexueller ..." usw. Das passt so inhaltlich gar nicht zu einem Boolean-Field. Entweder ist die Person ein Mann (wieder J/N) oder Frau (wieder J/N) oder was auch immer. Hier hättest Du allerdings einige boolsche Felder. Du möchtest aber eine Auswahl haben (M/F) !
Die Darstellung deiner boolschen Werte kann ich in IBO nicht bewerten, weil ich es schon seit vielen Jahren nicht mehr einsetze und mein Gedächtnis auch nicht das Beste ist.

Gruß Thomas

[Kostas]

Hallo Thomas,

das ist mit völlig klar. Natürlich könnte ich Interger nehmen als Bool.
Es ist für mich nicht verständlich das T/F gehen soll und J/N nicht. Wenn nur 0/1 gehen würde,
würde ich die Frage nicht stellen und mich damit abfinden. FB unterstützt es nun mal und ich habe
für Boolean sehr gerne J/N verwendet oder auch andere Kombinationen wie M/W. Das ich das mit einer
LookUp machen kann ist ebenfalls klar und habe ich auch rege im Einsatz. IBO hat das eben auch
unterstützt und ich sehe dass FireDAC es nicht unterstützt.

OK, das Thema können wir somit abschließen.

Gruß Kostas

P.S.
Wenn du DBX, FireDAC oder auch AnyDAC verwenden solltest, würde ich dich fragen wollen wie du den mit
dem SQL-Editor auskommst der nicht die Möglichkeit bietet die vorhandenen Tabellen und dessen Felder schnell innerhalb des Editor zu haben. Geht dir das nicht ab? Hast du alle Tabellennamen und Felder
im Kopf?

[TRomano]

Hallo Kostas,

ich arbeite mit UniDAC von DevArt (Gewohnheit) und bin damit zufrieden. Allerdings veranstalte ich da keine großen Sachen mit dem SQL-Editor, aber zu mindestens generiert er mir zuverlässig die INSERT/UPDATE/DELETE/REFRESH-Statements in der TUniQuery. Er zeigt mir alle Fields an, ich kann den PK auswählen und, und, und ... Was will man mehr ?
FireDAC brauche ich derzeit nicht und da ich (nur) die Prof.-Edition von XE6 benutze müsste ich diese auch noch zusätzlich erwerben. Und das alle (ca.) 6 Monate ... mache ich nicht mit.

Gruß Thomas

[Lemmy]

@Kostas:

Bevor du deine Char-Boolean in Integer umwandelst - bitte halt einen Moment inne!

Aktuell: Du willst J/N, Firedac speichert aber T/F
Neu: Du willst 0/1, Firedac speichert aber T/F

Fällt dir was auf?

der "einfachste" Weg: Änder dein Boolean in ein T/F. Bisher habe ich auch keine Möglichkeit (auch nicht über die Felddefinition) gefunden hier Firedac von T/F abzubringen (wobei ich kein FireDAC Fachmann bin und auch nie werde).

Der (IMHO) sinnvolle Weg: Geh weg vom Datenbankkontext! Sprich verwende keine Datensensitiven Komponenten mehr, sondern bau dir ne Zwischenschicht ein oder verwende ein vorhandenes ORM (DORM oder ien KaufORM) - dann hast Du deutlich mehr Möglichkeiten! Vor allem wenn DU eh von IBO mit den eigenen DBKomponenten weg gehst, dann ist das die Möglichkeit, das sinnvoll umzubauen. AUch wenn es ein deutlich größerer Aufwand ist - glaub mir der wird sich lohnen!

[Neutral General]

Wir haben in der Datenbank ein CHAR(1) für Boolean und benutzen dann halt Feld.AsString := 'J'/'N' um die Werte zu setzen. Ggf. eine kleine Helper-Funktion schreiben die true/false in J/N umwandelt und umgekehrt.

[Uwe Raabe]

Zitat:

Zitat von Neutral General (Beitrag 1278656)

Ggf. eine kleine Helper-Funktion schreiben die true/false in J/N umwandelt und umgekehrt.

Die ist ja, wie DeddyH in Post #6 schon schrieb, dank des DisplayText-Properties nicht notwendig.

[Neutral General]

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:

Delphi-Quellcode:

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 :/

[MichaelT]

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.

Zitat:

Zitat von Neutral General (Beitrag 1278661)

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:

Delphi-Quellcode:

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 :/

[EgonHugeist]

Hallo,

ich habe mal mit Zeos7.2 vom SVN-Repo Tests mit FireBird-3.0-Beta gemacht. FB3 unterstützt BOOLEAN Felder.. Wäre vielleicht eine Option?
Alles andere ist tatsächlich improvisiert und entspricht, wie mehrfach angedeutet, keinem SQL-Standart. Ich persönlich, würde daher dem FireDac Verhalten 100% Recht geben und einfach mit Calculated-Fields arbeiten.. Morgen fällt dir in deinem Projekt ein anderer Switch ein, der auch schnell mit 'T/F','J/N','0/1' zu lösen wäre und dann würde dich das Darstellen von Wahr/Falsch o. True/False für dieses Feld(TBooleanField) nur stören...

Gruß Michael

[user0815]

Ich würde immer noch den Kram auf Integer umswitchen:

Code:

CREATE TABLE TEST (
  NR  INTEGER  NOT NULL,
  WERT  INTEGER  DEFAULT 0,,
 CONSTRAINT PK_TEST PRIMARY KEY (NR)
);

Delphi-Quellcode:

const
  BooleanToInteger : Array[Boolean] of Integer = (0, 1); // 0=False, <> 0 somit True

...  
        SQL.Add('INSERT INTO TEST');
        SQL.Add('(NR, WERT)');
        SQL.Add('VALUES');
        SQL.Add('(:NR, :WERT);');
        ParamCheck := True;
        ParamByName('NR').AsInteger := 1;
        ParamByName('WERT').AsInteger := BooleanToInteger[True];
      
var
  OK : Boolean;
begin
...
  OK := FieldByName('WERT').AsInteger <> 0;

Abfrage & Anzeige

Code:

SELECT NR, 
       CASE WERT 
            WHEN 0 then 'False'
            WHEN 1 then 'True'
            ELSE 'Unknown'
       end AS WERT
FROM Test;