On Thursday, March 9, 2017 4:20:56 PM EST you wrote:

> On 2017-03-09 19:23, 'William L. Thomson Jr.' wlt-ml@...
>
> [Firebird-Java] wrote:
> > Seeing a bit of inconsistency. For some this works, for others not. I
> > cannot explain why it works for some and not others. Database are the
> > same charset.
> >
> > jdbc:firebirdsql:my.domain.com/3050:/path/to/data.fdb?lc_type=NONE
> >
> > This seems to be more reliable. I have not had any problems
> > connecting.
> >
> > jdbc:firebirdsql:my.domain.com/3050:/path/to/data.fdb?charSet=ISO-8895-1
> >
> >
> > Both do not seem to be required, but do not seem to hurt if both are
> > set. Just seems charSet is more reliable than lc_type. I think the
> > lc_type allows Jaybird 3 to work with Firebird < 3. When you have
> > Jaybird 3.x and Firebird 3.x, you need to use charSet not lc_type.
>
> Jaybird doesn't have a connection property lc_type, so observations that
> lc_type=NONE don't work can be explained by that. You need to use
> lc_ctype (or its alias encoding). Non-existent connection properties are
> ignored. In Jaybird 2.2 and earlier lc_type=NONE might seem to work,
> because that was the default for lc_ctype anyway.

That was a typo, I mean lc_ctype. For some reason I had some inconsistency
with that.

> Also be aware that using charSet=ISO-8859-1 is equivalent to using
> lc_ctype=ISO8859-1 (or lc_ctype=ISO8859-1&charSet=ISO-8859-1); it is not
> the same as using lc_ctype=NONE (nor using
> lc_ctype=NONE&charSet=ISO-8859-1), unless all the columns in your
> database are NONE or ISO-8859-1.

I likely should not have been using NONE. That was just what Jaybird 2
defaulted to so I was experimenting with that. Since the DBs are ISO-8859-1,
just using that.

Though may switch to UTF-8. I avoided it due to bloating the db without any
change in data. But that is seeming to happen with FB 3.x as is, so not sure
switching to UTF-8 will bloat it any more.

> In Jaybird 2.2:
> * lc_ctype=NONE means use connection encoding NONE and interpret
> everything using the default JVM encoding (eg Cp1252 on Windows in
> Western Europe (+ US?), UTF-8 on most Linux environments)
> * lc_ctype=NONE&charSet=ISO-8859-1 the same, but instead of the JVM
> default, use ISO-8859-1

I was likely not using character sets correctly at all. Though since not
working with special characters, and most of ISO-8859-1 maps over to UTF-8,
though not so much in reverse. I never had issues with older versions of
Jaybird.

> In Jaybird 3.0:
> * lc_ctype=NONE means connection encoding NONE and interpret columns
> with character set NONE using the default JVM encoding, and interpret
> columns with an explicit character set in their equivalent Java
> character set
> * lc_ctype=NONE&charSet=ISO-8859-1 the same, but instead of the JVM
> default, use ISO-8859-1
>
> In both versions:
> * lc_ctype=<firebird charset>* use connection encoding <firebird
> charset> and interpret in the equivalent Java character set
> * charSet=<java charset> use Firebird equivalent of <java charset> as
> connection encoding and interpret in <java charset>
> * lc_ctype=<firebird charset>*&charSet=<java charset> use connection
> encoding <firebird charset>, but interpret in <java charset>

Thanks that helps. Not sure I have seen it broken down like that before. Not
sure I need both lc_ctype and charSet. Mostly just needed to set something for
Jaybird 3. Due to requiring that now.

But I guess to be safe, one should set both.


--
William L. Thomson Jr.