> Then the new behaviour of connecting with NONE do exactly the trick.

As long as you guarantee bidirectional conversion rules between NONE and any
other charset... For now that's not the case. Currently OCTETS serve this
purpose, but the padding character for CHAR columns is 0x00, not 0x20,
therefore it cannot be widely used.

> Jaybird get the string in original charset (and know what is this charset)
> and convert to UCS2.

Correct.

> Roman, when it will be possible to connect with UTF16 or UCS2 are there
> any other reason to have charset package in JayBird?

The charset package was introduced not because of impossibility to use UCS2
as connection charset, but in belief that it brings performance compared to
native Java conversion tables. It was created by Blas Rodrigues Somoza
during the main performance optimization refactoring and if I remember
correctly, Blas reported either 5% or 10% performance growth on string
operations.

Personally I think the best mode from the performance point of view is to
let the server send the bytes to the client without converting it to the
client charset. This allows to put the db charset <-> UCS2 conversions to be
distributed over multiple processors (read client machines). Therefore I do
not see the reason to remove the existing code from JayBird.

BTW, John, you can think about extending JayBird encodings package with your
character sets. Then the conversion will happen in the driver itself and no
additional work will be needed. Note, you can always specify the client
character set for the database and the character set that should be used to
convert String<->byte[]. If you specify only one parameter, the second is
derived from the default conversion map, but if you specify both, server
will send data in the encoding you specified as client charset, but driver
will use the second param to convert bytes to strings.

Roman

Roman