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:

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:

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.

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.