Geoff,

>>>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).

Your explanation is very accurate and well articulated.

This indeed is the difficult challenge that I face and consequently that we
all face.

This is why I am forking the IBO code base between 4.9 and 5.x.

There are those who will be content to remain with the ANSI focused code of
4.9 and having such makes their migration far more straight forward.

There is also the need to completely revisit everything and clean up the
entire library to make use of new language features, including the unicode
functionality. This is actually just one part of things.

IBO 5.x is going to address other things as well. Having a driver layer for
the API is something that must be addressed to deal with FB and IB being on
divergent development tracks. Other DBMS' won't be brought into the picture
until after IBO 5.x is stabilized for FB and IB. The first step toward
supporting other DBMS' would be to write a driver for DBX so that any
database with a DBX driver would be able to have an IBO front end. Thus, as
I do this, I will be looking at FB, IB and DBX for the basis of code
factoring.

Thanks,
Jason Wharton