Sorry. This forum format is not the easiest to use. I did a direct download of the Dropbox files. The primary content.xml file was pointing to the Dropbox folder of the other person working on the files. I modified both “file” entries in that file, replaced the file in the .ODB structure and opened the revised file. I got the same error but it referenced the other person’s Dropbox folder. I searched all the .XML files in all folders, but could not find anything. Stumped.
JohnD
I even looked in the hsqldb.jar file and found nothing there.
JohnD
Couple of questions. Are you working from a linked Dropbox folder? After modifying the content.xml file, then after getting the error again, did you perhaps re-check that the changes made to the content.xml file were still there?
Don’t understand - “I even looked in the hsqldb.jar file and found nothing there.”
While waiting, here is what I did. Have Dropbox just for testing & answering questions. Linked folder. Connected to Dropbox. Copied to a new folder - database folder, driver folder & xxx.odb file. Opened xxx.odb with archive manager (Linux), modified both file names ( xxx.odb location & hsqldb.jar loaction), saved the changes. Opened the xxx.odb without any problem & independent of Dropbox files.
In your original question you mention “…some related files.” What are these and how are they related?
There are two Calc (.ods) sheets and a Writer (.odt) file. The problem I am having is trying to do a Data > Refresh to the Calc sheets. That is where I am getting the hsqld.jar error.
I am changing the extension from .odb to .zip, unzipping the file, modifying the content.xml file, rezipping, and changing it back to .odb. In the Edit>Database>Properties, if I try the “Test Class” or “Test Connection”, I receive an error: “The driver class org.hsqld.jdbcDriver could not be loaded”.
Having this information is important. This is why it is important to either be concise in the question or answer questions asked. Original comment asked about .obt file. Now it is apparent it is an .odt file - misspelling. Original answer stated ‘…question is not exactly clear as to where or what is the actual problem’. This may help in future for you when asking questions. In all fairness, you did state in question error was on related file. However, I got stuck on the database side.
When an embedded DB is split, the “Test Class” or “Test Connection” are no longer functional. Unfortunately, it returns an error instead of a better message. Now for the Writer/Calc problem. Data Sources in these are only obtainable via Registered databases. In your situation, you most likely have the data source pointed at the incorrect .odb file. From the menu go to Tools->Options then under LibreOffice Base->Databases insure the registered name points to the correct database.
Depending upon your setup, you may actually have to set this as a new registered name. In that case the Data Sources in the documents would also need to be changed.
I had renamed the .ODB file and registered it as LO would not allow more than one registered DB with the same name. That did not help. I unzipped the .ODS file and searched the content.xml, but no Data Source was in it. Looking at this now, it really won’t get us anywhere. There will eventually be several people working on these files. Having them updated in the Dropbox folder which is in an individual’s local User folder will just cause a nightmare.
We need to have everyone set up the same folder structure on their computer (such as “C:\LO_DB”), have all changes made there, and then copy those files to their local Dropbox folder where they will be updated to the Dropbox server. That would eliminate any specific references to one person’s computer. The question is how do we eliminate those references from the existing files? I found the .ODB references but not the .ODS ones.
When using Dropbox use a synced folder and run from there. This keeps the the dropbox files up to date without moving things around. The registered name of the DB is retained locally in LO so it can be used across all LO modules. Using Dropbox and having multiple users updating the files requires co-ordination. No two can update simultaneously. View this post for one users solution.
Just a further note of clarification. User A gets access to Dropbox files. User B also gets access. If they each move these from the Dropbox folder and work on them locally, when placed back in the Dropbox folder it will replace (not an update of data) the files. So User A replaces the files first, then user B replaces the files & user A’s work is lost.
Just looked at one of my Calc files with a DB link - it is in the root content.xml. I found my connections by doing a search on table/query name used. Registered database name is also in there.
I understand the potential problem with multiple users accessing the same file and making individual changes. We would have to set up some process to allow only one person at a time to change a particular file. That is what the post you reference discusses. It also mentions setting up a separate folder where changes would be made and then copied to the Dropbox folder for updating to the Dropbox server. That is my thinking as well.
I looked at the content.xml file for one of the Calc sheets in question and could not find any directory reference. How are you searching? He set up some macros in some of these. I looked under the LibreOffice Basic Macro and noticed that under the .odb reference was a “Standard” > “Embedded” section which indicates the the HSQLDB is “installed”. Does this have any affect?
Please see edit in my answer.
Ratslinger,
We finally got it sorted out. I am not exactly sure what it was. It could be that I was renaming the .odb file but not the files in the “database” subfolder. I deleted everything I had (folders, files, registered names, etc.), re-downloaded the files from Dropbox, copied them to a new folder, and registered the database. I was then able to do the Data > Refresh. Thanks for your help.
You’re welcome. Had already gotten the word. The specific problem was the registration of the database. The database you are using has the ability to be moved from location to location and work without modification. The associated file(s) were originally set to access the DB based using a specific name, the registered name. When you received the file, the name was not registered with this original name and this name pointing to the new DB location. Once done, you were back in sync.