Is it possible to tweak TStringField to work like

Question

We want to use Unicode with Delphi 2009 and Interbase, and found that to switch the character encoding from WIN1252 to UNICODE_FSS or UTF8 we first have to replace all instances of TStringField with TWideStringField in all datamodules. For around 60 datamodules, we can not simply do this over one weekend. I can see only two options for a migration strategy:

• find a workaround which allows to use the existing TStringField fields without triggering the 'expected: TWideStringField' error

or

• remove all persistent fields to avoid the string type conflict

As far as I know the field types for persistent database fields are registered in some kind of class registry. Could we use this to make Delphi believe that a TStringField is ok for a Interbase character column with UNICODE_FSS or UTF8 encoding?

Or can we use a commercial dbExpress driver which work with TStringField in both cases?

See also my related question: Delphi dbExpress and Interbase: UTF8 migration steps and risks?

---

Update: after replacing all occurences of TStringField with TWideStringField in all DFM and PAS files, we found that it is now also necessary to multiply the 'Size' property value of the TWideStringFields by four (if we use UTF8) in some 100 places. So I start a bounty for a way to reduce the manual work to fix the DFMs

Answer 1

Sergey A Kryukov, ‘Unicode Controls: What Can VCL Do?’, The Delphi Magazine, 116 (April 2005), p. 33-43 (Source code) The Delphi Magazine

Unfortunately, the text of the original article is not freely available, but ask me if you have questions.

Answer 2

Using TStringField for unicode characters will get you into trouble, it will have $00 in it, basically ending the string with, for example, dbExpress drivers, as these accept P(Ansi)Char strings. Using TWideStringField uses PWideChar in dbExpress, so the driver is expecting true unicode codepoints.

There's no easy way out, I'm afraid.