stringfield vs widestring field

[tygrys]

My database is using ANSI encoding (WIN1250)
My Delphi is unicode - XE.

I have a code:

Code: Select all

      
      Query.SQL.Text := 'SELECT Tekst FROM table';
      with TStringField.Create(Query) do 
      begin
        FieldName := 'Tekst';
        Name := 'tableTekst';
        Index := 0;
        DataSet := Query;
      end;
      Query.FieldDefs.Update;
      Query.Open;

I get the EDatabaseError: 'Type mismatch for field 'Tekst', expecting: String actual: WideString'.

I need to set ControlsCodePage to cGET_ACP to let it work as needed. But as said before in 7.0 Beta thread, for unicode Delphi this should be set to cCP_UTF16. I'm confused here.

[EgonHugeist]

tygrys,

IMHO, this behavior is expected. Well it might be possible you don't know how Delphi-Unicode behaves in this case? The TStringField doesn't allow the UnicodeString. Delphi does cast all Strings down to AnsiStrings. Your Database-Encoding with 1250 doesn't matter for Zeos. The implementations we have do savely convert all codepages up to the UnicodeString. You won't have any speed decrease here. Controls CP GetAcp starts allways from the premisse the TStringField is used and all character/text-fields are TStringField/TMemoField.

Whaich means assign a TStringField with a UnicodeString Delphi cast the Strings down to AnsiStrings in the FieldBuffers and on reading vice versa. Curious? Yes it is.

If your create a TWideString-Field instead, than your code should work too.. Right?

[tygrys]

Which means assign a TStringField with a UnicodeString Delphi cast the Strings down to AnsiStrings in the FieldBuffers and on reading vice versa. Curious? Yes it is.

This is a right path, because table field is if fact AnsiString and the control use unicodestrings. So the conversion is right at this moment.

If your create a TWideString-Field instead, than your code should work too.. Right?

Yes, but there is no need to have a WideString TField to hold AnsiString data - as it is AnsiString on the database side. I do not want a TWideStringField here, because if I switch to other data access components they will assume a TStringField here - and a transition will be painfull. Now I have only to implement connection and query create methods.

There was no such problem with Zeos 7.0 Beta EH branch, at least to November edition I used before.

Can you confirm that if I work only with Ansi strings on the database side I can safely use cGET_ACP in Delphi XE? Are there any side effects of this? Or I miss something here ?

[EgonHugeist]

tygrys,

I don't know anything about side effects. Our current tests don't show me something like that. Thats why i introduced the TZControlsCodepage-option. It's your choice what you want.. This enum simple tells Zeos which FieldTypes should be assumed. This option is much more interesting with the Ansi-Compilers where Wide/ANSI/UTF8 support is much more interesting.

[mac_srv]

Hi,

I have the same problem (please let me know if I might start a new thread):

EDatabaseError: 'Type mismatch for field 'Name', expecting: String actual: WideString'.

My C++Builder code is querying a Firebird 2.5 database/table with VARCHAR(20) fields, mapped as TStringFields and linked to TZQuery in a TDataModule.

Here is my basic connection description:

ControlsCodePage = cGET_ACP
Firebird 2.5
ZeosLib 7.2.0-beta
RAD 2009

Reading this thread, I've expected that cGET_ACP should avoid this error.

Note: the same code is working with BDS 2006, so I think it is really the case of ControlsCodePage usage, isn't it?

Thank you in advance,

Marcelo.

[mac_srv]

Hi,

I'm sorry about the last post. I now realized a mistake and I would like to share it in order to not misleading other readers.

Setting "ControlsCodePage = cGET_ACP" works properly as expected.

I've done a mistake into my code just before setting a "ROLENAME" property:

Code: Select all

ZConnection->Properties->Clear();  //Here is the problem. Comment or delete this line.
...
ZConnection->Properties->Add("ROLENAME=" + PrmRoleName);

Thanks anyway.

Marcelo.

[raosistemas]

in my SQL the solution is the same?

[EgonHugeist]

Indeed, it is..