On 29-6-2012 11:49, the_a_rioch wrote:

>> If so then i am completely at loss, how is that rational choice.
>> Use whatever you like, even LATIN1 but do report your assumption in effect to server so server could adapt itself to your workings.
>
> from #JDBC-257
> "The connection characterset would remain NONE, but the encoding used in FBStringField would change to match the database"
>
> Ehh? Same trick again ? Report de jure one charset but de facto use different one ?
> You gonna cheat again? You gonna lie to server ?
> And you think that would - in the long term - end well ?

You are aware that this is exactly the same way that Firebird server
works. If the connection characterset is NONE, Firebird will send the
content of CHAR and VARCHAR in the encoding of the database AS IS,
otherwise it will transliterate from the database characterset to the
connection characterset (unless that DB charset itself NONE, then it
will just send the stored bytes AS IS). So matching the encoding of the
database would ensure the exact same representation in String on the
Java side as in the database which in my mind would be the best way to
handle it.

If you have a better idea, make a detailed proposal and not just say in
broad strokes that we are wrong.

> God save us.
>
>> I truly hope that i misundertood something, otherwise i have a gooseskin.
>
> I probably should better say "ants running my back" but i'd also probably refrain from speaking of ants on this list ;-)

I have to say that I find your way of discussing and criticizing design
decisions that were taken over 10 years ago (probably even earlier for
Borland InterClient) and essentially telling us we are idiots very
annoying and it doesn't really inspire to respond to your posts at all.

Mark
--
Mark Rotteveel