TryStrToFloat/TryStrToInt, leeren String nicht als 0 erhalten

[Delphi.Narium]

Das Integer in der DB Null sein kann ist klar, aber dazu muss dann die Schnittstelle auch Null liefern und nicht aus 'nem leeren String eine 0 machen.

Also ein Versuch:

Ein Leerstring per .AsString in ein nummerisches Feld der Datenbank, führt nicht zwingend zu einem Null in der Datenbank sondern (vermutlich) eher zu einer 0.

Ein Leerstring per .AsString in ein Stringfeld der Datenbank, führt nicht zwingend zu einem Null in der Datenbank sondern (vermutlich) eher zu einem Leerstring.

Null bekommt man eher per .AsVariant := EmptyParam in die Datenbank, dabei sollte der Feldtyp nicht von Belang sein.

So besser oder hab' ich was übersehen, unklar formuliert, ...? Bin mir da halt nicht so wirklich sicher.

[Uwe Raabe]

Zitat von Delphi.Narium:

Ein Leerstring per .AsString in ein nummerisches Feld der Datenbank, führt nicht zwingend zu einem Null in der Datenbank sondern (vermutlich) eher zu einer 0.

Vermutlich? Ich kann dir versichern, dass es nicht so ist - bestätigt durch Lesen der Sourcen und Ausprobieren. Kannst du gerne selbst prüfen.

Zitat von Delphi.Narium:

Ein Leerstring per .AsString in ein Stringfeld der Datenbank, führt nicht zwingend zu einem Null in der Datenbank sondern (vermutlich) eher zu einem Leerstring.

Zumindest bei Verwendung von FireDAC kann man das über ein Property der Connection steuern: TFDFormatOptions.StrsEmpty2Null

[Delphi.Narium]

Zitat von Uwe Raabe:

Zitat von Delphi.Narium:

Ein Leerstring per .AsString in ein nummerisches Feld der Datenbank, führt nicht zwingend zu einem Null in der Datenbank sondern (vermutlich) eher zu einer 0.

Vermutlich? Ich kann dir versichern, dass es nicht so ist - bestätigt durch Lesen der Sourcen und Ausprobieren. Kannst du gerne selbst prüfen.

Zitat von Delphi.Narium:

Ein Leerstring per .AsString in ein Stringfeld der Datenbank, führt nicht zwingend zu einem Null in der Datenbank sondern (vermutlich) eher zu einem Leerstring.

Zumindest bei Verwendung von FireDAC kann man das über ein Property der Connection steuern: TFDFormatOptions.StrsEmpty2Null

Da wir hier von ZeosDB reden, und es dort datenbankabhängig (leicht) unterschiedliche Implementierungen gibt, kann ich halt (pauschal leider) nicht mit absoluter Sicherheit sagen, welches Verhalten zu erwarten ist.

Und da ich kein XE2 habe und auch keine Sourcen dazu, kann ich nicht im Quellcode nachschauen und mit Sicherheit sagen, wie das Verhalten dort genau sein kann, soll, darf oder muss.

Bei meinem Delphi werden per ADO Integer bzw. Float per .AsString := '' zu Null, ein VarChar wird mit .AsString := '' zu einem Leerstring.

Ist das so ein klar definiertes Verhalten, das bei allen Dantenbankkomponenten zu erwarten ist?
Dann sollte das im Eingangspost beschriebene Problem mit der grundsätzlichen Nutzung von .AsString := Edit.Text bei Integer- bzw. Floatwerten zu lösen sein.

[Uwe Raabe]

Zitat von Delphi.Narium:

Ist das so ein klar definiertes Verhalten, das bei allen Dantenbankkomponenten zu erwarten ist?

Das das Verhalten bereits von TIntegerField in Data.DB implementiert wird, müsste eine andere Zugriffsschicht schon eine eigene TIntegerField-Komponente mitbringen, die das dann auch noch anders (und somit inkompatibel) löst.

[freimatz]

Zitat von jaenicke:

Stichwort nullable types:
https://dalijap.blogspot.com/2020/05...m-managed.html

Damit kannst du einen Leerstring auch als Nullwert speichern und so auch in die DB schreiben.

Gibts in Spring4D schon.

[Frickler]

Mach Dir nen eigenen Datentyp, ein record oder eine Klasse mit dem eigentlichen Wert und einem Flag "gesetzt" und die passenden Methoden dabei, u.a. ein Setter und ein "WriteToField(ds: TDataSet; const fn: string)", bei dem Du dann je nach "gesetzt" entweder den Wert übergibst oder das Feld unverändert lässt oder auch löschst.
Statt "TryStrToFloat" musst Du dann sowas wie "try StrToFloat... gesetzt := true; except .. end" nutzen. Vielleicht gleich als Methode mit in den eigenen Datentyp packen.

[cltom]

Zitat von Frickler:

Mach Dir nen eigenen Datentyp, ein record oder eine Klasse mit dem eigentlichen Wert und einem Flag "gesetzt" und die passenden Methoden dabei, u.a. ein Setter und ein "WriteToField(ds: TDataSet; const fn: string)", bei dem Du dann je nach "gesetzt" entweder den Wert übergibst oder das Feld unverändert lässt oder auch löschst.
Statt "TryStrToFloat" musst Du dann sowas wie "try StrToFloat... gesetzt := true; except .. end" nutzen. Vielleicht gleich als Methode mit in den eigenen Datentyp packen.

den Teil kann ich mir noch gut vorstellen, aufwändig, aber denkbar, aber dann die SQL-Befehle basteln. Da muss man dann bei jedem einzelnen Wert erst mal prüfen, ob das Flag gesetzt ist. Da erscheint es fast leichter, das Flag einfach mitzuschreiben in die SQL, weil dann der SQL-string im Grunde unverändert bleibt. Es wird alles geschrieben (Null oder nicht), aber eben auch das Flag wird geschrieben, sodass ich beim lesen das wieder gesetzt hab.

oder seh ich das falsch an Deinem Ansatz? sonst ist die Idee ja schön mit dem Record, weil man das Verhalten dann auch standardisieren kann

[Frickler]

Zitat:

den Teil kann ich mir noch gut vorstellen, aufwändig, aber denkbar, aber dann die SQL-Befehle basteln. Da muss man dann bei jedem einzelnen Wert erst mal prüfen, ob das Flag gesetzt ist. Da erscheint es fast leichter, das Flag einfach mitzuschreiben in die SQL, weil dann der SQL-string im Grunde unverändert bleibt. Es wird alles geschrieben (Null oder nicht), aber eben auch das Flag wird geschrieben, sodass ich beim lesen das wieder gesetzt hab.

oder seh ich das falsch an Deinem Ansatz? sonst ist die Idee ja schön mit dem Record, weil man das Verhalten dann auch standardisieren kann

Du brauchst in der Datenbank kein extra Flag. NULL ist schon das Flag.

Für alle leeren Felder schreibst Du NULL in die Tabelle. Für alle NULL Werte in der Tabelle liest Du ein leeres Feld. Bei Berechnungen in SQL kannst Du mit COALESCE() die NULL Werte in 0 wandeln, falls nötig.