>> P1: do two-phase connection to query database default charset (or even set of all used charsets), choose charset broad enough to support all that data (win1251 or UTF8 or whatever). Reconnect.
>>
>> Drawback: on long lines where TCP connection takes long time - that would double the delay.
>> Answer: Those who are really affected, would learn to fix charset in JDBC URL. Those who are not would get best possible charset at price of barely noticeable delay.
>
> Because of the performance implications this is in my opinion not a good
> option.

Agree.

>> P2: do try UTF8 connection. If it happened to be FB1.x w/o UTF8 support - re-connect with fallback to some connection wit hall those problems.
>>
>> Drawback 1: those with FB1.x would get potentiallyslow two-phase connection.
>> Answer 1: They can fix it by specifying encoding in URL. That would stimulate them for safer practice. Also that would stimulate them to upgrade to FB2 and lessen support efforts.
>
> As we are dropping explicit support for Firebird versions 1.0 and 1.5 in
> Jaybird 2.3 this is not really a big problem. However a big drawback is
> if somebody has been using a characterset NONE databases with connection
> characterset NONE all these years (or actually (almost) any database
> characterset combined with connection characterset NONE). In the current
> situation you can be blissfully unaware of this situation and everything
> will just seem to work in almost all cvases (until your local system
> encoding changes).
> If we would default to connect with UTF-8 either you get all kinds of
> transliteration errors or data is now stored in two different encodings:
> in other words you introduce logical data corruption.

There will be no data corruption. Server will fail before - it won't
know how to convert NONE to UTF8, so no data will be delivered to the
client.

(will check the rest of your email later)

Roman