On 29-6-2012 13:53, the_a_rioch wrote:

>>> 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.
>
> no
>
>> If the connection characterset is NONE, Firebird will send the
>> content of CHAR and VARCHAR in the encoding of the database AS IS,
>
> yes
>
>> So matching the encoding of the
>> database would ensure the exact same representation in String
>
> no
>
> NONE means "no transcoding", pass binary data non-changed.
> It means "there is NO language context"
> It means "that is supposed to be raw binary data and client takes all responsibility how to find text there, if it exists at all"

There is no other option, because it will *NEED* to be converted to
Strings in Java due to JDBC requirements and therefor you *HAVE* to
select an encoding.

Mark
--
Mark Rotteveel