Subject Re: [Firebird-Java] Re: Denied connections due to character set
Author William L. Thomson Jr.
On Tuesday, February 14, 2017 4:54:22 AM EST Mark Rotteveel
mark@... [Firebird-Java] wrote:
> On 14-2-2017 04:24, 'William L. Thomson Jr.' wlt-ml@...
>
> [Firebird-Java] wrote:
> > The fun continues.... Thus far nothing works. I first ran into this only
> > with 3.x but now is happening with all version of 2.x. It is not
> > happening on my servers just on desktop applications.
> >
> > I tried the various combos, where you see spaces below, NONE UTF8
> > ASCII...
> > That means I did each combo, with -Dfile.encoding, and without. All
> > produced each error.
> >
> > This combo produced this, pretty sure same for ISO-8859-1 and ISO8859-1
> >
> > -Dfile.encoding=ISO8859_1
>
> Be aware that -Dfile.encoding specifies the **Java** system(!) default
> encoding, it expects Java encodings (ISO8859_1 happens to be a valid
> alias, but not all Firebird character set names are valid aliases for
> Java character sets), for example NONE is not a valid Java character set
> name.
>
> You should almost never have a reason to touch the file.encoding
> setting. Why are you setting this value?

I am just trying to connect via ANY means.

> If you are setting it to control how NONE works, then you would be
> better off specifying both the connection encoding NONE and the Java
> character set with lc_ctype=NONE&charSet=iso-8859-1, although just
> specifying charSet=iso-8859-1 is probably better in that case.

Ok I will try that. That is exactly the combination I was saying the
documentation was vague. Its probably been there for some time, but I was not
aware that lc_type and charSet could be used together or in that manner. That
may be exactly how it will work for me. The only way I can connect using
Jaybird 3.

> > url?lc_type=ISO8859_1
>
> The correct property is lc_ctype (or its alias encoding), but judging by
> the errors below you are actually using lc_ctype.
>
> > Feb 13, 2017 9:50:51 PM org.firebirdsql.logging.JulLogger warn
> > WARNING: No EncodingDefinition for ISO8859_1 / null specifying ISO8859_1
> > as connection encoding
> > java.sql.SQLNonTransientConnectionException: No valid encoding definition
> > for Firebird encoding ISO8859_1 and/or Java charset null
>
> How are you running your application, did you by any chance build a fat
> JAR, instead of adding the Jaybird jar to the classpath?

No, but the wrong jar was copied into a application directory rather than
using the systems.

> This problem could be explained if the encoding definition file is not
> on the classpath when running. This might happen if you built a fat
> jar, and did not include
> org/firebirdsql/encodings/default-firebird-encodings.xml from the
> Jaybird jar in your own jar.

dev ~ # unzip -l /usr/share/jdbc-jaybird/lib/jaybird-full.jar | grep \\.xml
6395 02-14-2017 10:55 org/firebirdsql/encodings/default-firebird-
encodings.xml

> Looks like I will need to add a fallback to define this in code as well...
>
> > -Dfile.encoding=NONE UTF8 ASCII
> > url?lc_type=NONE UTF8 ASCII ISO8859_1
> >
> > java.sql.SQLException: Your user name and password are not defined. Ask
> > your database administrator to set up a Firebird login.; Install
> > incomplete, please read the Compatibility chapter in the release notes
> > for this version [SQLState:28000, ISC error code:335544472
>
> This error indicates you are trying to connect to Firebird 3 and haven't
> initialized the security database yet. Please check the Firebird 3
> release notes.

I have been using Firebird 3 for some time now, many months. Pretty sure I
have all security database setup. I can connect fine via Jaybird 2 and
Flamerobin.

> > url?lc_type=NONE&encoding=NONE
> >
> > org.firebirdsql.jdbc.FBSQLException: Specified properties contain
> > reference to a DPB parameter under original and alias names: original
> > name isc_dpb_lc_ctype, alias : encoding
>
> This error indicates that you have specified both lc_ctype and encoding.
> Encoding is an alias for lc_ctype and you should specify a property only
> once.

Yeah that is the one error that made sense.

--
William L. Thomson Jr.


[Non-text portions of this message have been removed]