>> The character set for connection is specifies in DPB, the property is
>> called lc_ctype. If the property is not specified, then server assumes
>> NONE. This logic is coded in Firebird, not in driver.
>
> And probably ages back to Groton and single-language environments.

To american way of thinking - they have only 26 characters and they pass
into lower 7 bits of charset table, and there is no rest of the world
with funny characters. :)

But Jim have recognized that long time ago - all his next creations have
only string data type (no max length) and all are Unicode.

>> The only right solution would be to ditch the NONE defaulting on the
>> server, then we would default to UTF-8, and everybody would be happy.
>
> U mean
> 1) server uses UTF8 defaulting if not specified ? then i strongly disagree. That is a road to hell, you upgraded server and silently corrupted database.

Server gets a default charset for newly created databases configured
during installation. So, when you specify in ISQL

CREATE DATABASE bla.fdb USER foo PASSWORD bar;

then the default charset of the database is not NONE, but UTF8 or
WIN1251 or whatever is specified there.

The server will not assume a different charset than the one is specified
in the database. So, for those databases that are created with NONE, it
will remain NONE with the same behavior as is now. But all new databases
will have some charset specified.

> 2) server denies no-lc_type connections. Clients learn to always specify something. JayBird specifies UTF8. - That sounds reasonable.

Yes.

> Afterall there are not that much clients out there. fbclient.dll is one and Jaybird is another. Any third client ? So they all can be upgraded to add their own default, in same sole action with server upgrade.

.NET Client another one, it also implements wire protocol.

Roman