'General Error' & 'The driver class “” could not be loaded.'

fcsw · September 15, 2025, 6:11am

Windows 10 22H2
Version: 25.2.5.2 (X86_64) / LibreOffice Community
Build ID: 03d19516eb2e1dd5d4ccd751a0d6f35f35e08022
CPU threads: 2; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded

I started the app I’ve been working on and got ‘General Error’. No forms were visable. Clicking on the tables got ‘The driver class “” could not be loaded.’. Back up copies run w/out errors. In Tools->Options->Advanced->Class Path I clicked the Archive button and set “\hsqldb.jar”. I set Driver Class to “org.hsqldb.jdbcDriver”. I no longer get “General Error”, but now I get “The connection to the external data source could not be established.”, so apparently this is not how I connect to the embedded database.

What do I have to do to reconnect to the embedded database & get the existing forms & tables?

RobertG · September 15, 2025, 7:42am

If you want to use the internal HSQLDB never set an entry for HSQLDB in the Class Path.
.
All tests should be made with a copy from the original database.
.
What do you see if you try to start the Base file? Add a screenshot here.
Could you open a older version of this Base file?

fcsw · September 15, 2025, 8:41am

Too late. I thought I would just do a couple of settings & restore the file.

I’m no longer getting the “General Error” message. Only this:

The last backup runs fine. Screenshot:

Note that the backup indicates an embedded HSQLDB database, while the corrupted file just says “JDBC”.

RobertG · September 15, 2025, 9:32am

Might be this helps:
https://books.libreoffice.org/en/BG73/BG7311-AppendixA-CommonDatabaseTasks.html#toc18
Could be the content.xml inside the Base file only connect to the wrong database type. Should be

<db:connection-data>
<db:connection-resource xlink:href="sdbc:embedded:hsqldb"/>
<db:login db:is-password-required="false"/>
</db:connection-data>

for a internal HSQLDB.

Villeroy · September 15, 2025, 10:24am

Install https://forum.openoffice.org/en/forum/viewtopic.php?f=21&t=86071
Open your Base document.
Run macro pyDBA>ExtractHSQL>Revert_To_Embedded

fcsw · September 16, 2025, 4:54am

@RobertG I tried your suggestion. It took care of the immediate problem. I got “HSQLDB EMBEDDED” at the bottom of the window, & I could navigate to the tables & open them. The one I checked seemed to have all its data. However, when I tried to open a form, I got a message that the manifest.rdf file was in the wrong format. When I checked, it contained 0 bytes.
.
I unpacked a backup copy of the odb file into its own directory, & did the same with the corrupted file. I used dir & fc (this is a windows machine) to compare file sizes, & it turns out the corrupted odb is missing a lot of data in many files. Unpacked, the complete corrupted odb file is missing > 600 KBytes of data. The point of trying to recover the odf file was to recover some code I had restructured just before the odb was corrupted, but while the backup has 254 Kbytes of data in the Basic directory, the corrupted odb has 5. For the module I modified, the corresponding file contains 0 bytes.
.
Bottom line, the modified code is gone & I don’t think it’s worth while to pursue this any further. I’ll just have to do that work over again. Luckily I make lots of backups, so that’s the only thing I have to recreate.

fcsw · September 16, 2025, 5:01am

@Villeroy, your solution probably would have worked, but I decided the file was too corrupted to recover what I wanted to recover. The specific file for the module containing the code I had worked on contained 0 bytes. Thanks for your effort. I gave your post a like.

Villeroy · September 16, 2025, 12:43pm

Generally speaking, it is a good idea to extract embedded HSQL. A stand-alone database will not crash as likely as an embedded one, which is extracted every time you start a session and repackaged when you finish it. Having an embedded HSQLDB up and working, the Main routine of my Python module can extract the database and reconnect the Base document to the extracted database.

fcsw · September 17, 2025, 6:13am

That’s true for production databases where you need to protect your data. This is a development db. My primary concern is protecting the code. Splitting the db won’t help with that. I’ve got nightly backups going back 9 months for this project. Unfortunately this crash happened just before the backup, so it wiped out a night’s work. I did a lot of work that night restructuring a complicated routine. I’m in the process of doing it all over.
Once the app goes into use & contains real data, it would be crazy not to split the db. I bookmarked your link for future reference.