On 29-6-2012 9:46, the_a_rioch wrote:

>> Actually, blobs are always sent in their defined characterset
>
> with that characterset bundled, or driver should separately query "what charset it was supposed to be for column/blob-id x?")

It is in the XSQLDA together with the data.

>> (a thing
>> BTW which I believe Jaybird currently doesn't handle well when the blob
>> characterset deviates from the connection characterset). The driver
>> should take of conversion here, not Firebird.
>
> Scanning through Jaybird_2_1_JDBC_driver_manual...
> Out of line, that table of mapping between Java and FB types, could you add there numeric codes like that "-1" ?
> Why for Javist it would be lame question, "use the source, Luke" for outsiders that would require an investigation "where and what to search for".

I will consider it, but this is more a limitation of Hibernate that they
don't report the java.sql.Types name which is failing.

> After reading "Appendix D. Character Encodings" i think that current heuristics about NONE has just no sense at all.
> There is UTF-16 charset in Java, there is some unknown charset in DB, and you introduce yet another, 3rd charset !
> Okay, imagine that heavy-loaded FB server is running on Linux. Client desktops on Windows. Under this logic, there would be (assuming Russian as the language):

This is exactly the same way that other Firebird drivers work when
connecting using NONE. In the Java world the local system encoding is
considered to be the 'default' encoding.

> 1) database language - unknown yet before connection. Valid guesses would be NONE, UTF8, Win1251 (if database was designed on local Delphi/IBExpert/etc Windows box, then moved to server), KOI8-R (if designed on Linux from start).
> 2) default OS charset (file.encoding) on server would be KOI8-R, unknown before connection
> 3) default OS charset (file.encoding) on client would be 1251
> 4) Java application internal charset would be UTF-16 (for Russian it would be the same as UCS-2, used by Windows API, if i get it right)
> 5) Jaybird's heuristics would ( from my POV - ignoring and overriding connection's NONE charset) assume connection charset charset of 3) which has high chances to differ from server's one.
>
> I believe you had a rational and good thought of choice for defaults but i just cannot see any rationale behind that.
> Sorry for being harsh, that is just how i really feel - completely lost on that subject.

Well, lets agree to disagree.

> Also that appendix D in manual seems full of ambiguous wording to my eye.
> "When the NONE character set is used, the driver does not know how to interpret the received data."
> Driver is just a intermediate bridge. So was it about data, it receives from server ? Or was it data it receives from JDBC/application ? And why it "does not know" if it can query the server while reading schema and it can assume UTF-16 on JDBC endpoint ?

Because in most cases that would be wrong as well.

Mark

--
Mark Rotteveel