Bug 34411 - External and internal HSQLDB must be usable in different versions
Summary: External and internal HSQLDB must be usable in different versions
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
3.3.1 release
Hardware: x86 (IA32) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Database-Import
  Show dependency treegraph
 
Reported: 2011-02-17 12:53 UTC by Robert Großkopf
Modified: 2018-12-14 16:19 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 2011-02-17 12:53:32 UTC
I wanted to use the external HSQLDB. Tried this in OOo 3.1.1. It works
with a "little" mistake. In the properties-file of the intern databases
is written the version from the extern hsqldb.jar.

So with newer versions of OOo or LibreOffice the files could not be opened. They were blocked with a warning, that the file is created with a newer version of
hsqldb.

LibreOffice 3.3 handles it the same way if you will use an external and an
internal version of hsqldb. You could not change any data of internal
database after saving the file and trying to open it again when there is
an external hsqldb.jar with a newer version in the classpath.

For a normal user like me it is a bug, that it does not work. Why
couldn't LibreOffice distinguish between internal and external version of
hsqldb?

A warning when trying to open the database is ok, if there could be lost
data. So it could be a problem when using the version 2 of hsqldb, but
not the version 1.8.1.2 external and the 1.8.0.10 internal.
Comment 1 Alex Thurgood 2011-02-18 00:48:34 UTC
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
Comment 2 Robert Großkopf 2011-02-18 07:00:17 UTC
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
Comment 3 Björn Michaelsen 2011-12-23 11:51:50 UTC Comment hidden (obsolete)
Comment 4 Robert Großkopf 2011-12-29 12:42:09 UTC
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.
Comment 5 Alex Thurgood 2013-01-14 09:49:26 UTC
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
Comment 6 Alex Thurgood 2013-01-14 09:51:13 UTC
Putting Stephan on CC, as this has probably something to do with the Java loader. Stephan, any ideas ?


Alex
Comment 7 Stephan Bergmann 2013-01-14 10:20:59 UTC
(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.
Comment 8 Fred Toussi 2013-01-28 16:54:48 UTC
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.
Comment 9 dacm 2013-02-07 22:47:58 UTC
(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?
Comment 10 Fred Toussi 2013-02-10 16:23:51 UTC
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.
Comment 11 bfoman (inactive) 2013-07-20 20:19:49 UTC
(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.
Comment 12 Robert Großkopf 2013-08-16 07:29:17 UTC
(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.
Comment 13 Robert Großkopf 2013-08-24 07:07:41 UTC
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.
Comment 14 Alex Thurgood 2013-08-26 08:27:36 UTC
(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
Comment 15 Alex Thurgood 2015-01-03 17:41:00 UTC Comment hidden (no-value)
Comment 16 QA Administrators 2016-01-17 20:04:24 UTC Comment hidden (obsolete)
Comment 17 Alex Thurgood 2016-11-23 08:32:13 UTC
Bug still present in LO5233 (macOS)
Comment 18 QA Administrators 2018-09-19 02:51:12 UTC Comment hidden (obsolete)
Comment 19 Alex Thurgood 2018-09-19 07:38:44 UTC
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...
Comment 20 Alex Thurgood 2018-09-19 07:43:38 UTC
If I remove the classpath added hsldb.jar and restart LO, everything goes back to normal...