--- In IBObjects@yahoogroups.com, Geoff Worboys <geoff@...> wrote:

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

Thank you, Geoff! You covered exactly my concerns.

Konstantin Oleynikov
BroadView Software Inc.