Am 19.03.2010 02:38, schrieb Geoff Worboys:

>> Let me try and clarify. Both IBO 4.x and IBO 5.x should work
>> with all of the character sets that Firebird/InterBase support.
>> [...]
>>
> I would argue that IBO 4.x has only ever worked with single-byte
> character sets, certainly not all IB/FB support. This is not
> a criticism of IBO, it was able to offer only this level of
> support because that's all Delphi did until 2009. Sure there
> was the "WideString" type... but not a lot of a good when there
> where no components written to use it.
>
> And in all this IBO only ever accepted what it was given and
> hoped that the developer/user managed to match the connection
> character set with what the user (Windows) was actually using.
>
> Now that Delphi has unicode and now that Firebird (since v2.1)
> gives useful character-set information via the existing API
> it is possible for IBO to do much better... and to do so with
> not much effort on it's part.
>
> At least that is the plan and the intention of my code... it
> remains to be seen whether I truly manage it. (I know it is
> possible because I've done it in C++/Qt code.)
>
>

I have seen the same in python code (KInterbasDB).

>
>> Ok, perhaps I did not understand what you said property. I
>> prefer to leave the handling of character sets to the database
>> and the OS as much as possible. I would not eagerly delve into
>> a project that required too much in the way of custom
>> transliteration routines on the client.
>>
> Nothing very difficult about what I have done so far. I simply
> created a list of Firebird character-set identities and match
> them to Windows code-pages. With the character-set detail
> returned from Firebird v2.1 I can give Delphi the code-page
> required to convert the input bytes to a unicode string and
> vise-versa.
>
>

Most work is done by the firebird client lib.
If the connection string is utf8 we get all bytes of normal char fields
in utf8.
If the connection string is win1252 we get all bytes of normal char
fileds in Win1252.

To get the value as a string we need to convert them to Unicode (always
possible).
To get the value as AnsiString we need to convert them to the actual
Codepage (not always possible).
Whenn I implemented it, I found out that IBO (and other Client libs,
too) make a lot of mistakes handling connnection char sets.
I create database with ISO8859-1, connection char set Win1252, so I had
no problem to input an euro sign.
But now, when I connect with Utf8, there is no euro sign anymore,
because the conversion from ISO8859-1 to Utf8 (in client lib) to Unicode
(in Delphi) is not the same as using the same bytes for different Charsets.

> Assuming I have gotten the code right (big assumption) this
> should work for all predefined Firebird character-sets (don't
> know about Interbase but perhaps someone who watches IB can
> help out in that regard).
>
>
>
>> Start with the sample applications and I'll see what I can
>> do from there.
>>
> Hmmm... samples don't make a very good test library - too much
> user interaction to run many tests quickly and easily. And
> most of the samples are gui based and I have not converted all
> that stuff yet.
>
>
>

My test machine is a VM ware xp system.

The very few Test Case at sourceforge are testing against FB 1.5 to 2.5
and are working with D5 to D2010.
Every FB Server is working on another port (no one at default port).
The bin directy is using the default pathes for firebird servers.
This is necessary to create, backup and restore databases.
The test configuration has default values, which can be overwritten.

Installing the different delphi versions was no problem, starting with
the lowest version of delphi.