On 13-2-2017 23:32, 'William L. Thomson Jr.' wlt-ml@...
[Firebird-Java] wrote:

> Last time I was on the list was in 2008. I am pretty displeased at the
> circumstances that are forcing me to re-subscribe. I have already opened a bug
> on this issue.
>
>
> I first noticed this issue/change with jaybird 3.x. I am VERY displeased that
> it has been back ported to 2.2.12, essentially breaking jaybird for existing
> applications.

This change was not backported to 2.2. If you have the same problem with
2.2, then you have a different problem.

> I am VERY upset over this, as I have NEVER had an update of Jaybird break
> existing applications. Nor have I ever had any issues connecting to database.
> No matter what I set, where how etc. I CANNOT connect to my databases using
> jaybird 2.2.12 or any 3.x version.
>
> This need to be fixed immediately! It is one thing to make such major change
> for 3.x. That should never have been done to 2.x. There should be CLEAR
> documentation that works. I have messed around for HOURS trying all sorts of
> methods and NONE work.

If you have the same problem with Jaybird 3 beta and Jaybird 2.2.12,
then your problem is not one of character sets.

> When I get past the connection issue, I run into other issues with the
> character set not matching that of my database. I have NEVER had to set a
> character set, nor had any problems in over a decade of usage. This is
> completely unacceptable to be making such a change and breaking existing
> function.

Could you please describe the problem in detail, and showing some code,
configuration, etc that you use.

> http://tracker.firebirdsql.org/browse/JDBC-479
>
> Really never seen a change like that frustrate me so much. I have spent WAY to
> much time trying to get something to work. That used to work just fine. That
> should work per various attempts, but does not.

That is unfortunate, but you only once left a comment on JDBC-446 about
this in november, and I couldn't contact you for more information
because my email sent to your email address on the tracker was rejected
by your mail server.

If instead you had contacted me directly or through this mailinglist,
some frustration might have been avoided.

> There is no clear documentation or steps. Which clearly shows that someone is
> ASSUMING how to get past this issue. Even the error output is EXTREMELY vague.
> I have tried every method and NO difference.

There was a bug in the default connection character set handling that
will be fixed in Jaybird 3 beta 3, see JDBC-473. I have also updated the
documentation.

I appreciate constructive feedback, but I need more than just "EXTREMELY
vague". English is not my native language, and being deep down in the
technical workings of Jaybird will sometimes make things extremely
obvious to me that might not be so to others.

I have made some changes to the documentation, see
*
https://github.com/FirebirdSQL/jaybird/blob/master/src/documentation/release_notes.md#connection-character-set-none
*
https://github.com/FirebirdSQL/jaybird/blob/master/src/documentation/release_notes.md#connection-rejected-without-an-explicit-character-set

> java.sql.SQLNonTransientConnectionException: Connection rejected: No
> connection character set specified (property lc_ctype, encoding, charSet or
> localEncoding). Please specify a connection character set (eg property
> charSet=utf-8) or consult the Jaybird documentation for more information
>
>
> Ridiculous!!!!! Unacceptable!!!! Absolutely unnecessary!!!

This change is necessary in my opinion, because the character set
handling of NONE has lead to surprise in the past, including corruption
of data. Furthermore, the handling of NONE was changed in Jaybird 3 and
that can lead to unexpected behavior. If you want to use NONE, that is
fine, but that should be an explicit decision on your part.

For example if a column has an explicit character, Jaybird 2.2 and
earlier interpret that column in the local JVM default character
encoding, however Jaybird 3 will interpret the column in the specific
character set instead. This can lead to surprising character set
conversions or even transliterations errors if for example if all this
time you have been writing WIN1252 data into a WIN1250 column using
connection character set NONE.

Alternatives like using a new default like UTF8 have their own problems,
because if your database is largely NONE, then things won't work out
either, and if you have columns wider than 8191 characters that will
lead to all kinds of exception (truncation, string length exceeded, etc).

Mark
--
Mark Rotteveel