>>Hi, all! We are currently porting project source heavily
>>dependable on IBObjects from Delphi 7 to Delphi 2010. Are
>>there plans to move from AnsiString to UnicodeString?

> http://tech.groups.yahoo.com/group/IBObjects/message/44409

> Read that. :-)

Yes... although that rather misses the point.

From Delphi v2009 onward there is the basic assumption that
an application will use unicode. Most of the VCL and most
third party components continue to use the "string" type
making such code assume unicode when compiled under D2009+.

What we get with an "ANSI" version of IBObjects is a library
in which we must distort our D2009+ unicode applications to
interact with an ANSI interface. For example:

. TIB_Column.AsString is ANSI where TField.AsString is unicode
so TDataSet compatibility stuff is going to get difficult.

. large parts of the IBO interface are inherently unicode (the
many string lists are unicode) while others have been
artificially forced to ANSI.

I am still trying to work out what all this will mean to IBO
applications being migrated to D2009+... what worries me is
such migration - using this "ANSI" version of IBO - will make
it more difficult to later migrate using a later unicode
version.

I would contend that IBO is not D2009+ compatible... it may be
possible to compile and execute but that is a much lower
standard than compatibility.

I understand that there are difficulties with the fact that
much of the FB API is not unicode and that many databases for
apps being migrated are not unicode either... so at some
point string conversions must occur. However what I want from
a database access library is something that hides those
difficulties from the rest of the application (rather than
bringing them to the front and making them my problem in
every application that uses the library).

--
Geoff Worboys
Telesis Computing