On 28/02/2013 5:16 PM, Mark Rotteveel wrote:

> Could you describe the problem you had with Jaybird?
> I might need to create some additional documentation.

After downloading and plugging in jaybird-2.2.2.jar into the classpath
for LibreOffice, my first challenge was that I kept (and still get when
I use that jar) an error that "the driver class
'org.firebirdsql.jdbc.FBDriver' could not be loaded." This was actually
the one biggest issue. The documentation suggests that
jaybird-2.2.2.jar should have the "JDBC driver, the JCA connection
manager, the Services API and event management classes" with the full
driver having the "[s]ame as above but also the connection pooling
classes". So I figured the first jar was what was normally used, and
the other one used when connection pooling was also needed. And since
I knew that there were complications to getting the driver to work for
embedded, so I didn't try the other jar for quite some time, figuring I
had made a mistake somewhere else. I set the FIREBIRD environment
variable, I set the PATH for where I dropped the DLL, I fussed with the
naming of the embedded server DLL, since its instructions said I might
have to call it fbclient.dll or gds32.dll. In the end, though, it
worked when I finally switched from jaybird-2.2.2.jar to
jaybird-full-2.2.2.jar.

All the setup required for this, maybe it's still common in Unix land,
but manually installing an embedded server and setting environment
variables is not something I can ask the end users I want to distribute
my database to to do. And dropping random DLLs "somewhere in your
path" is something that no Windows user should be forced to do any
more. Especially on 64 bit systems, this can be dangerous. You don't
want to drop a 32-bit DLL into a directory reserved for 64 bit system
libraries, for example. End users should never have to manually copy
libraries around. Anything executable should always be put in place by
an installer so it can be removed with an uninstaller.

> Using the native protocols like embedded is a bit
> more work than using the Java wire protocol, but it
> is usually nothing more than putting the jaybirdxx.dll
> and the embedded binaries in the root of your application
> (or on the PATH).

I'm not developing an "application". Or rather, I suppose I am, but
it's an end-user sort of thing using Libre/Open Office. I'm not putting
together an installer - I'm not a VAR. So maybe Firebird just isn't for
me. It seems to me, though, that a little bit of consolidation would
make Firebird usable by a much wider audience. I can see no reason why
the embedded "server" is not included right with the client installer.
Neither can I understand why ODBC and JDBC are also not installed right
with the client. One stop shopping for all your Firebird client needs.
No DLLs to copy into paths, no environment variables to set. The added
size for everything together is trivial. The projects can even be still
kept separate with the latest release of each tapped for each client
release.

> I guess your problem was specifically with using it in
> Base as native library loading, correct locations for
> binary dependencies etc gets complicated, and the native
> driver doesn't actually work correctly with Base (the
> workaround in the jdbc:firebirdsql:oo protocol is only
> for the Java wire protocol).

I did get some funny behaviour using it. For example, I couldn't use
the navigation buttons to force the cursor to the very end of the result
set. But this was largely a non-issue since the general performance was
too sluggish anyway, so I didn't do much investigation into the causes
of this. It may be, as you say, because of the problems with
Libre/OpenOffice that you made the "oo" workaround for.

> As far as I know most JDBC drivers don't include DLLs in
> the jar. Doing that also seems to require a 'dirty' trick
> (extracting the DLL to a temporary location and then loading
> it) which I didn't even know before I googled it now.

This is less of a dirty trick, I think, than telling an end user to drop
the DLL into a random PATH directory, and far less than having Firebird
put databases into "Program Files" which is a huge Windows no-no. At
least when the client cleans up, it can delete the DLL. There's a lot
of software that drops executable bits into temp folders. Every
installer program on the planet, for one. Most games, also, for copy
protection DLLs and even services. This is a common, and generally
accepted practice in Windows. Better than having end users hand manage
it. I admit, it's not really very cross-platform. Does Jaybird
automatically look in the directory where the jar is for the DLLs it
needs? I didn't try this myself, because the documentation I read
seemed to indicate it had to be on the path, and I was trying to
diagnose the problem with the driver class not loading at the time.

Hope any of this helps.

Kurt.