[No solution] Split db connects under Windows, but not Linux

dBase, Calc, CSV, MS ACCESS, MySQL, PostgrSQL, OTHER
Post Reply
fcsw
Posts: 12
Joined: Sun Aug 31, 2025 8:49 am
Location: Mars

[No solution] Split db connects under Windows, but not Linux

Post by fcsw »

Edit: I didn't think to check bugzilla until after I posted. From the comments to bug 34411:
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.
Elsewhere in the comments someone found that Mac/LO had the same problem as Linux/LO.

There may be no one on Earth using Win/LO and Linux/LO together in the way I'm using them. But if someone does try it, this is the reason a tandem upgrade to 2.x doesn't work, and it probably isn't going to be fixed. On the other hand, if you use HSQLDB 1.8.0.10 under all OSs, everything works fine.
---------------------------------------------------------
Win 11 25H2
LO Version: 25.8.3.2 (X86_64)
Build ID: 8ca8d55c161d602844f5428fa4b58097424e324e
CPU threads: 6; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded

Windows Subsystem for Linux (WSL)
Ubuntu 24.04.3 LTS
LO Version: 24.2.7.2 (X86_64) / LibreOffice Community
Build ID: 420(Build:2)
CPU threads: 6; OS: Linux 6.6; UI render: default; VCL: gtk3
Locale: en-US (C.UTF-8); UI: en-US
Ubuntu package version: 4:24.2.7-0ubuntu0.24.04.4
Calc: threaded

I do LO development on Windows. In order to check that the code runs correctly and everything looks right on Linux systems, I've got Ubuntu and LO running under WSL, as detailed above. Windows can see the Ubuntu file hierarchy, but Ubuntu can't see anything outside of its own file hierarchy. For convenience, I've had one copy of my odb file in the Ubuntu hierarchy, which I accessed both with LO running under Windows and LO running under Ubuntu. This worked great until I split the database.

I used Villeroy's database splitter to do the work. It worked fine in the regular Windows file hierarchy. It threw out a bunch of errors when I tried running it from Windows in the Ubuntu hierarchy, but I was able to hack the Python script to fix that. The thing I can't figure out how to fix is the fact that under Ubuntu, the split LO/HSQLDB database is running version 1.8.0.10, even though the driver is 2.4.1. When I run the splitter under Windows, the resulting split db is 2.4.1. Under Ubuntu, even though

Code: Select all

ThisDatabaseDocument.DataSource.JavaDriverClassPath
contains the correct path for the 2.4.1 hsqldb.jar file, pasting

Code: Select all

Call "org.hsqldb.Library.getDatabaseFullProductVersion"()
in the SQL window returns 1.8.0.10. In case it matters, the path is

Code: Select all

file:///home/fcsw/ResourcesProject/ResourcesProjectSplit/driver/hsqldb.jar
For comparison, pasting

Code: Select all

Call database_version()
in the SQL window after splitting under Windows returns 2.4.1.

The same thing happens with the FreeHSQLDB extension. It runs under Windows, I hacked it to run under Windows in the WSL hierarchy, but under Ubuntu LO either runs 1.8.0.10, or if you open an odb file that was split under Windows, it can't connect to the backend.

Under the File menu, if I set up a new database connection, LO successfully loads the driver file but then can't make a connection.

I'm trying to avoid creating a Windows-only app, but I have to split the database to protect the data. For future development I want to be able to use capabilities that are only available in later versions of Hsqldb.

So the problem for which I need a solution is: How to get Ubuntu/LO to load a 2.4.1 hsqldb.jar driver file and connect to a backend db.
NASA Mars Rover Hacking Project: Martians supplying Earth with bogus scientific data since 1997.
Post Reply