In the Delphi 2009+ implementation, you have to use AsString
property for AnsiString
and AsWideString
for
string=UnicodeString
.
In fact, the As*String
properties are defined as such:
property AsString: string read GetAsString write SetAsString;
property AsWideString: UnicodeString read GetAsWideString write SetAsWideString;
property AsAnsiString: AnsiString read GetAsAnsiString write SetAsAnsiString;
How on earth may we be
able to find out that AsString: string
returns in fact an
AnsiString
?
It just does not make sense at all, when compared to the rest of the
VCL/RTL.
The implementation, which uses TStringField
class for
AnsiString
and TWideStringField
for
string=UnicodeString
just appear to be broken.
Furthermore, the documentation is also broken:
Data.DB.TField.AsString
Represents the field's value as a string (Delphi) or an AnsiString (C++).
This does not represent a string
in Delphi, but an
AnsiString
!
The fact that the property uses a plain string=UnicodeString
type
is perfectly misleading.
From the database point of view, it is up to the DB driver to handle Unicode
or work with a specific charset.
But from the VCL point of view, in Delphi 2009+ you should only know about one
string
type, and be confident that using AsString:
String
will be Unicode-ready.
If you use our mORMotVCL.pas
unit, it will behave as
expected.
Thanks you sjerinic
for your input and patience about this issue!
Feedback is
welcome!