Hi Emile,

--- "h_urlaf" <h_urlaf@y...> wrote:

> Charset-agnostic? There's always going to be a charset somewhere.

Not the most clear term, I used. Independant on the actual character
set. Able to connect to databases of varying charsets.

> Or
> do you mean to make it configurable in the connect string... hmmm...
> will FB transliterate the strings as I fetch them then?

FB will transliterate, but that can become more a burden than a
benefit sometimes. From my judgements, only three cases work consistently:

a) DB charset NONE, connection charset NONE
The paradise of the ignorant. Nothing can go wrong, but you get what
you pay for.

*** here is the charset canyon: only use everything NONE or nothing
NONE or dragons will kill you ***

b) DB charser: your preferred one; connection charset same

c) DB charset varying, connection charset UNICODE_FSS

The last one looks promising, but report your results. There may
be still bugs lurking.

And coming back to the charset agnostic application.

In homogenous systems, you can use approach b) and select the "native"
charset of system as db + conn charset. Only in cases where conversion
to and from external Unicode interfaces are to be done, your app has
to do something charset specific.

But you can also combine approach b) (as well as c)) with an app
working internally in Unicode (UTF16 for Win32 and UTF8 for Linux).

Enough confusion for the moment?

Regards,
Peter Jacobi

>
> Emile