r> setBytes(...) will not work too, simply because in FBStringField
r> everything goes through the setString(...) method.

:((((


r> - DBMS converts data you passed taking into consideration character
r> encoding of the connection and column, and if conversion is not
^^^^^^
but there is no way to use encoding
with the driver for a given column
that does not use the default
database encoding.
r> possible, exception is thrown.


r> DBMS expects data in the encoding you specified during connection. If
r> that was UNICODE_FSS, then the data passed to DBMS should be
r> UNICODE_FSS. If that was WIN1250, then data should be WIN1250.

Yes, I understand this, but you should also understand that we're
speaking about TWO encodings. When lc_ctype is WIN1250 I can send 0xF5
to the driver, when lc_ctype is different (e.g. NONE, or WIN1252) I
can not. Problem is there is no way to pass 0xF5 *to the JDBC driver*,
because it assumes my string is encoded (but this is a different
encoding from lc_ctype) using Cp1250.

Java encoding convert Unicode characters to 8 bit characters, but
lc_ctype (thus encoding specified for Firebird) *does not make* any
conversion. That is an interpretation, not a conversion. When I set
lc_ctype to WIN1250, I specify ONLY what characters are allowed in a
8-bit byte array, and how to order the strings with those characters.

That is the difference.

r> And that's exactly what driver is supposed to do: assume that you
r> pass the _correct_ unicode string, get the encoding of the connection
r> and convert that unicode string to the encoding of the connection.
r> And I hope that drivers works in this way.

Ok, but how can I pass a correct unicode string, if encoding is
encoding is different in a column from the connection lc_ctype. What I
want to make clear is that lc_ctype is _not_ an encoding. That is only
a method to make UPPER and ORDER BY work, but that is not an encoding.
Encoding converts ASCII characters to Unicode characters and vica
versa. If you send 0xF5 to Firebird, it will store 0xF5 in the database.
Maybe, if you don't set lc_ctype it will say that character is not
valid, but it won't convert it.

I think now it is clear that the main problem is I can't pass 0xF5 to
the JDBC driver, what you should see is that in many cases there is no
way to create a "correct" unicode string, because original encoding is
not known.

Moreover there is absolutely no hope to write data to column with
differenc character set with the current system.

>> As I mentioned still the problem is many system uses the 8-bit
>> encoding, even in Java, although theoretically you're right that you
>> expect the correct Unicode format, but practically this may not be a
>> perfect solution.

r> Ok, let people vote on this thing.

+1 vote to add an option to disable character set conversion. :)

daniel