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!
