Hi,

This problem also occurs with some Linux distributions that provide a different hdsqldb.jar for their own packaging reasons than the one against which LibreOffice is built. I believe that this bug also exists in the upstream OOo code. When the error occurs, the ODB file can not be opened, the workaround is to change the version number in the properties file of the ODB by hand, but ideally the user shouldn't have to worry or care about why the application software didn't write the correct version into the file, it should just do it properly.


That said, I don't think that there is much sympathy in the LibreOffice developer community for fixing hsqldb bugs. Most of the devs who have expressed any kind of opinion seem to want to move away from this kind of db engine.

Alex

Hi Alex,

That said, I don't think that there is much sympathy in the LibreOffice
developer community for fixing hsqldb bugs. 

Is this really a hsqldb-bug. Couldn't it be the same problem with any other internal and externat database?

Most of the devs who have expressed any kind of opinion seem to want to move away from this kind of db engine. 

But what kind of db-engine do they want to install. Or would it go back to a frontend without any db-engine? I had tried the external version, because this is the easiest way to get data out of the *.odb-file an use the data the same way as before: All queries, all forms and all reports work.

For professional working a mysql-database is the better solution, but for private use or learning in scool the way with internal hsqldb is easier to use.

Robert

Tested it now with different versions internal and external. Seems to work with external HSQLDB Version 1.8...., doesn't work with the new version 2.2.6. There comes an file input/output error in the internal databases (java.lang.NullPointerException.properties). When I delete the hsqldb.jar I added in the classpath the internal databases work.

Hi Robert,

Sorry about not getting back to you on this, but I can confirm this also on Mac. If you plug in an external path to the v2 hsqldb.jar, the internal Base/hsqldb combo then stops working altogether :-/ with the error message you indicated.


Alex

Putting Stephan on CC, as this has probably something to do with the Java loader. Stephan, any ideas ?


Alex

(In reply to comment #5)
> If you plug in an external path to the v2 hsqldb.jar, the internal
> Base/hsqldb combo then stops working altogether :-/ with the error message
> you indicated.

Adding an additional instance of hsqldb.jar to the JVM classpath is a very crude mechanism, as any attempt at loading a class with a name that is present in both hsqldb.jar instances will necessarily load the class version from the additional hsqldb.jar.  Without looking at the code in question, this is likely to cause any kind of confusion.

The issue with dual version HSQLDB will be fixed with the release of 2.3.0. An alternative jar will be released at the same time as the standard jar. This can be used side-by-side with an HSLQDB jar of an earlier version.

(In reply to comment #8)
> An alternative jar will be released at the same time as the standard jar.
Will the alternative jar work with SQLTool?

The alternative jar will be compatible with SqlTool, as well as any program that uses HSQLDB. The alternative jar will have a slightly different name for the jdbc driver and the first part of the JDBC URL. So the connection settings will be slightly different from the normal jar.

(In reply to comment #2)
> But what kind of db-engine do they want to install. Or would it go back to a
> frontend without any db-engine?

Firebird - please see bug https://bugs.freedesktop.org/show_bug.cgi?id=51780.
Therefore this report is a WONTFIX candidate.

(In reply to comment #8)
> The issue with dual version HSQLDB will be fixed with the release of 2.3.0.
> An alternative jar will be released at the same time as the standard jar.
> This can be used side-by-side with an HSLQDB jar of an earlier version.

Hi Fred,

where do I get this alternative *.jar-file. I have just tested the hsqldb.jar from 2.3.0 and it works the same as before. Adding it to the classpath will destroy the version of internal hsqldb of LO.

I have just tested with the macro from here:
http://forum.openoffice.org/en/forum/viewtopic.php?f=40&t=61155#p270692
It is possible to connect with the same LO-Installation to the internal HSQLDB 1.8 and to the external HSQLDB, actually 2.3. Internal and external HSQLDB-databases could be opened at the same time.

If this is possible by only some lines of code in a macro for the external database I don't know, why it should not be possible to do the same in the internal code. There must only be a point which says to LO: For internal databases use the hsqldb.jar in the internal path of LO and it would work.

We couldn't say, that this is a wontfix-candidate. When the internal database would change to Firebird (and this is discussed a long time ...) we must have also installed the hsqldb.jar for the old internal *.odb-files.

(In reply to comment #13)

Hi Robert,

> 
> We couldn't say, that this is a wontfix-candidate. When the internal
> database would change to Firebird (and this is discussed a long time ...) we
> must have also installed the hsqldb.jar for the old internal *.odb-files.

In the current Firebird integration GSOC project, the user gets a UI choice in the DB Creation Wizard as to whether they want a Firebird embedded DB or a hsqldb.The plan, as far as I can tell, is to provide in the __longer term__ a migration path (wizard) from existing hsqldb embedded db to firebird embedded db, and then at some stage remove hsqldb altogether. 


Alex

Bug still present in LO5233 (macOS)

Testing with :

Version: 6.1.1.2
Build ID: 5d19a1bfa650b796764388cd8b33a5af1f5baa1b
Threads CPU : 8; OS : Mac OS X 10.13.6; UI Render : par défaut; 
Locale : fr-FR (fr_FR.UTF-8); Calc: group threaded

and hsqldb 2.4.1 as the classpath added jar file

still leads to the following error message when trying to display the tables in an existing embedded-hsqldb ODB file :

Impossible d'établir la connexion à la source de données "Buttontest".

Statut SQL: S1000
Code d'erreur: -452

file input/output error: /Users/alex/Downloads/Buttontest.odb.log


so I would say that the problem is still present...

If I remove the classpath added hsldb.jar and restart LO, everything goes back to normal...

Same here, LO 7.0.0.3 on Windows, tried to add HSQLDB 2.5.1 jar.

I’m aware that HSQLDB is slated to be phased out in favor of Firebird in the end, but there will still be legacy DBs using HSQLDB. Given the wide user base of LO, which includes a bunch of government/municipal institutions, where IT migrations of any kind can take a considerable amount of time, this issue is going to stick around for quite some time to come.

Rather than instructing users to use the alternate HSQLDB jar and slightly different JDBC URLs for external DBs, would it be an option to bundle an alternate version of the jar and use that internally, so users could drop in the standard JAR for external DBs? As the JDBC URL for embedded DBs is not normally exposed to the user, this would probably result in behavior which is less “surprising” to the user.

*** Bug 140268 has been marked as a duplicate of this bug. ***

Bug is still the same in LO 7.6.0.1 on OpenSUSE 15.4

Hi all,

I would like to express my opinion in this conversation.

I am not a Java specialist but its use has led me to notice several things:
- Once a JDBC driver is loaded, regardless of how it is loaded, you will only be able to use this version of the driver until LibreOffice is closed (the Java engine stops).
- There are at least 2 ways to load a JDBC driver.
  - By putting the driver in the Java classPath. But putting the jar archive in the ClassPath prevents any use of a URL Class Loader on this archive since when using a URL Class Loader, Java will look to load first by scanning the Java ClassPath then if it doesn't find it will use the URL Class Loader.
  - Using a URL class loader allowing you to fetch the correct version using the URL pointing to this version.

Under Linux if you install the components in LibreOffice allowing you to use HsqlDB in integrated mode then the HsqlDB 1.8 jar archive will be put in the Java ClassPath (this will prevent any use other than version 1.8). This is not true for the installation of LibreOffice under Windows... It is apparently a Java URL Class loader which is used.

I think that these limitations are immutable, we cannot do without taking them into account.