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!