4

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

Community
  • 1
  • 1
mjn
  • 36,362
  • 28
  • 176
  • 378
  • 4
    You can't do search/replace all in your 60 *.pas and *.dfm files over one weekend? IMHO, it should only take a few minutes. – Ondrej Kelle Mar 23 '10 at 14:40
  • @TOndrej: we will also need several hours for database migration and tests. And if the tests fail, we will have to repeat the whole procedure on the next weekend(s). This is not a greenfield project. So I am looking for a solution to have only one executable version which is able to work with the old and the new database - this should be possible because Delphi 2009 is already fully Unicode enabled. – mjn Mar 23 '10 at 16:58
  • You would have to to, if anything, even more testing with either of your proposed solutions. @TOndrej's suggestion is better, IMHO. – Craig Stuntz Apr 01 '10 at 15:00
  • @Craig today we found that it is also necessary to multiply the 'Size' property value of the TWideStringFields by four in some 100 places. And test, and repeat the whole procedure with the production system. – mjn May 18 '10 at 11:00
  • 1
    Do you REALLY need to multiply 'Size' by 4? I am using FibPlus 6.9.9 with UTF8 fields (not dbExpress), and the 'Size' does not depend on encoding (though UTF8 fields physically are 4 times wider than ANSI, the logical 'Size' property is the same and I think it should be the same). – kludg May 18 '10 at 11:33
  • @Serg yes, if we don't there are Access Violations. If I delete the original persistent field and add it again, Delphi automatically uses the new increased size. – mjn May 18 '10 at 11:49

1 Answers1

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.

Martijn Tonies
  • 453
  • 2
  • 9