stringdelphiansistring

Implicit string cast with potential data loss from 'string' to 'AnsiString' / ADOQuery


got here Delphi 10.3 Update 1. On the Form I have a ADOQuery which has a Field named ExtraText this field is TWideStringField .

In my Programm I assign it like this :

 PrintPosQueryRack.Value:=PrintPosQueryExtraText.Value;

if I hover the cursor over PrintPosQueryRack.Value I get System.WideString if I hover the cursor over PrintPosQueryExtraText.Value I get System.String

I really-really don't understand why . The PrintPosQueryRack is a Calculated Field , which I Created as plain string . Because I as far as I know in later Delphi versions string is Unicode (UnicodeString) in Delphi .

I also have a variable here strRack : string . If I assign it to PrintPosQueryRack.Value ( which is System.WideString ) , I get the same Warrning .

I can "fix" this by changing the strRack : string to strRack : AnsiString and by changing the PrintPosQueryExtraText.Value to PrintPosQueryExtraText.AnsiString .

But I am kinda lost here .

Thank you .


Solution

  • TL;DR: Use WideString as the type for your calculated field. StringFields are internally based on AnsiString.

    If you make a field of type String, (ftString), you get a TStringField. Its value is still the "old" AnsiString. This is probably for compatibility reasons.

    That is, it depends on the NEXTGEN define, which basically means the for classic desktop applications TStringField.Value is still an AnsiString, while for iOS and Android apps written in Delphi, it is indeed a (unicode) String.

    But that is only for the Value property. You can also use the explicit AsString, AsWideString or AsAnsiString properties. Those properties are available for any field type, but the value you give or get is translated to and from the internal type of the field. For TStringFields, that type is still AnsiString, regardless how you set the value.

    For unicode values, use WideString or WideMemo fields.