FireDac asString definiert unterschiedlichen Datentyp in SQLite je nach OS

[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.