FireDac asString definiert unterschiedlichen Datentyp in SQLite je nach OS

**fisipjm**

Hi,

gerade was kurioses entdeckt. Folgender Code funktioniert unter Windows Problemlos:

Delphi-Quellcode:

			if mydate > 0 then

    l_Query.ParamByName('date').AsString := DateToISO8601(mydate)

else

begin

    l_Query.ParamByName('date').DataType := ftString;

    l_Query.ParamByName('date').Clear;

end;

Hinter den Parametern steckt ein SQL Insert Skript. mydate ist ein TDateTime. Ziel des Codes ist, ich möchte in der Datenbank nicht den Standard "0" wert für das Datum stehen haben (1899 irgendwas) sondern, wenn ich kein Datum habe, dann möchte ich wirklich NULL in der Datenbank stehen haben. Firedac muss ich in dem Fall den Datentyp mitgeben, sonst verweigert er das clear.

Wenn ich diesen Code jetzt auf Android ausführe, dann erhalte ich zu Laufzeit die Fehlermeldung, das Versucht wird ein ftWideString in ein ftString umzuwandeln und das ein neuaufbau der Abfrage erfordert. Wenn ich alles auf Widestring umstelle, dann funktioniert es wieder.

Ich vermute jetzt, dass unter Android ein "AsString" automatisch zu einem "AsWideString" wird und dann das DB Feld entsprechen als WideString in die Query geladen wird. Wenn ich jetzt versuche explizit mit ftString den Datentyp auf ftString zu setzen knallt es.

Würdet ihr das als Bug sehen, oder ist das per Design so?

vG
PJM

**Uwe Raabe**

Man kann das direkt in TFDParam.SetAsStrings sehen:

markieren

Delphi-Quellcode:

			  if not (FDataType in [ftString, ftFixedChar, ftWideString, ftFixedWideChar]) then

    FDataType := {$IF DEFINED(IOS) OR DEFINED(ANDROID)} ftWideString {$ELSE} ftString {$ENDIF};

  Values[AIndex] := AValue;

Wenn du das nicht alles nachbilden willst, dann vielleicht so:

markieren

Delphi-Quellcode:

			if mydate > 0 then

    l_Query.ParamByName('date').AsString := DateToISO8601(mydate)

else

begin

    l_Query.ParamByName('date').AsString := '';

    l_Query.ParamByName('date').Clear;

end;

**TurboMagic**

Interessant. Wäre nur noch interessehalber die Frage, warum da für iOS und Android ein Unterschied gemacht wird bzw. werden muss...

**himitsu**

Weil es den String ShortString, oder war's AnsiString, dort offiziell nicht gibt.

**TurboMagic**

Hm? Liefert AsString keinen Unicode String?

**himitsu**

Der TStringField hat das AsString überladen/verdeckt und gibt .... [edit] ok, dachte war beim AsString, aber es mehrere Überladungen, wo der eigentliche Property überschrieben verdeckt wird.

zusammenfalten · markieren

Delphi-Quellcode:

			  TStringField = class(TField)

    ...

{$IFNDEF NEXTGEN}

    function GetValue(var Value: AnsiString): Boolean;

{$ELSE}

    function GetValue(var Value: string): Boolean;

{$ENDIF !NEXTGEN}

    ...

{$IFNDEF NEXTGEN}

    property Value: AnsiString read GetAsAnsiString write SetAsAnsiString;

{$ENDIF !NEXTGEN}

  end;

  TWideStringField = class(TStringField)

    ...

    property Value: string read GetAsWideString write SetAsWideString;

  end;

Da kommt es dann auch noch drauf an, ob du direkt eine Variable/FormField vom "richtigen" TField-Nachfahren oder eine Variable/Result, z.B. vom FieldByName, als allgemeines TField verwendest, wo du plötzlich unterschiedliche Property und somit auch ein anderes Verhalten nutzt.

**Uwe Raabe**

Zitat von TurboMagic:

Liefert AsString keinen Unicode String?

Schon, aber ftString resp. TStringField repräsentieren AnsiStrings, das erkennt man am Property Value. Das hat man damals bei der Unicode-Umstellung bewusst so gemacht, damit das kompatibel zu den bestehenden DB-Daten bleibt.

Warum das bei FireDAC auch auf TFDParam ausgedehnt wurde ist mir nicht ganz klar (insbesondere die unterschiedliche Behandlung nach Plattform). Bei TParam ist das zumindest nicht so - da wird bei AsString ein ftWideString draus.

Vermutlich wird nur Dmitry Arefiew das wirklich beurteilen können.

FireDac asString definiert unterschiedlichen Datentyp in SQLite je nach OS

FireDac asString definiert unterschiedlichen Datentyp in SQLite je nach OS

AW: FireDac asString definiert unterschiedlichen Datentyp in SQLite je nach OS

AW: FireDac asString definiert unterschiedlichen Datentyp in SQLite je nach OS

AW: FireDac asString definiert unterschiedlichen Datentyp in SQLite je nach OS

AW: FireDac asString definiert unterschiedlichen Datentyp in SQLite je nach OS

AW: FireDac asString definiert unterschiedlichen Datentyp in SQLite je nach OS

AW: FireDac asString definiert unterschiedlichen Datentyp in SQLite je nach OS

Forumregeln

TurboMagic Registriert seit: 28. Feb 2016 Ort: Nordost Baden-Württemberg 2.825 Beiträge Delphi 12 Athens	#3 AW: FireDac asString definiert unterschiedlichen Datentyp in SQLite je nach OS 17. Apr 2024, 19:01 Interessant. Wäre nur noch interessehalber die Frage, warum da für iOS und Android ein Unterschied gemacht wird bzw. werden muss...
	Zitat

himitsu Online Registriert seit: 11. Okt 2003 Ort: Elbflorenz 43.152 Beiträge Delphi 12 Athens	#4 AW: FireDac asString definiert unterschiedlichen Datentyp in SQLite je nach OS 17. Apr 2024, 20:36 Weil es den String ShortString, oder war's AnsiString, dort offiziell nicht gibt. Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher. my Delphi wish list : BugReports/FeatureRequests Geändert von himitsu (17. Apr 2024 um 20:40 Uhr)
	Zitat

TurboMagic Registriert seit: 28. Feb 2016 Ort: Nordost Baden-Württemberg 2.825 Beiträge Delphi 12 Athens	#5 AW: FireDac asString definiert unterschiedlichen Datentyp in SQLite je nach OS 17. Apr 2024, 21:12 Hm? Liefert AsString keinen Unicode String?
	Zitat