Hi, All.

>> A _huge_ amount of our users don't want any client installation. They put
>> fbclient.dll into their application's /bin directory and everything
>> works.
>> No need for any setup, no need to worry about DLL hell, no external
>> dependencies. This is what people love in Firebird. My strong opinion is
>> that everything else (beside the library code itself) on the client side
>> should be (1) located using the path rules (not registry) hence making
>> any
>> explicit installation not necessary and (2) optional (e.g. system MBCS
>> routines are used by default, like my namesake Sibiryakov suggests).
>
> That's very true!
>
> But there are other ways to do it.
>
> For example: fbclient.dll can make charset conversion (to and from
> UTF8) driven by definition files, like TCL does. The application defines
> the client charset and if it isn't ASCII, UTF8 or any Unicode
> encoding, then fbclient tries to load a definition file for the given
> charset (for example win1250.enc for WIN1250) or report an error.

And still other ways to do it.

A technique that I use very often is to store all the required conversions /
whatever on the server, and if necessary, store a local CACHE of the
conversions on the client. If a conversion is unavailable / out of date on
the client, then you just 'Go And Get It!'. This concept is really not
rocket science - it is quite trivial, and very powerful.

Implementation of this may be non-trivial (depending on how easy it is to
extend the comms protocol), but as an example to get it going / illustrate
the concept without too much pain, you could attach to the database from the
client with no specific conversion requirement, get the stuff required out
of a blob, for example, from RDB$CONVERSION_BLOBS or whatever, save the
conversion, disconnect and reconnect with the new conversion in place. I'm
sure there are dozens of better ways of doing this, but I have no clue as to
what is required on connection setup, etc, the comms protocol and how
extensible it is, or whether or not this stuff even belongs in each
database, or with the server build / loadable module itself. The concept is
what is required here.

To make this transparent to the application, you could bury the stuff above
/ whatever other implementation you can come up with in the client library,
so that it happens automatically.

It also means that if there is a nasty problem with a conversion, you can
get all your clients to automatically update their version by doing a
trivial comparison of the locally cached version and the server version by
using a hash digest, for example, and you're done. Forever. (Or until next
year, anyway. :) )

Larry