Going to take a shot at answering this. The question is not exactly clear as to where or what is the actual problem. There are a number of ways to split a DB and this solution is because the split DB is not portable. I have seen this error message (combined with the one in my comment) often and here is a fix:
You only have to change two things to fix this. Using a BACKUP COPY (always protect yourself), open the .odb with an archive manager. Right click content.xml file and open with a text editor. Look for:
data-source-setting-value>file:THE DIRECTORY CURRENTLY POINTED TO/hsqldb.jar
Example:
and change it to the correct location of the driver directory of the .jar file. Save the change and update the file in the archive. Second, run the .odb and from the menu select Edit->Database->Properties...
and make sure the directories in the Datasource URL are correct. Those two steps should fix the problem.
Edit 9/18/2017:
Hopefully this will clear up the problems and clarify many of the questions in the comments.
As stated above, there are many ways to create a split DB. Some automatically detect that the split DB has changed location and adjust accordingly. The above process is to fix those which don’t make this adjustment. If you can relocate your DB and it opens properly without a problem, then this issue can be ignored.
Saying that moving the DB itself is not a problem, let’s go on from there.
Dropbox. The link in one of the later comments actually contains two methods of use. One is to use the DB in the synced folder and the other is to move it to another until ready to save. This seems to be a matter of preference and I can see pros & cons for each.
Related Calc & Writer files. This is where I see the major portion of the problem. Data in these files is obtained by using the registered DB name. The fields set in the root content.xml files are set by this registered name and the table/query it comes from. Modifying this file to a different registered name is not recommended and can cause more problems than it may solve. Instead, each users’ system should utilize the same registered name. It can point to wherever the .odb is located on their system, but the name is key here.
So in your situation, you get the files from Dropbox. You move them to wherever on your system. We are using the basis here that moving the DB is not an issue and it automatically adjusts for its’ location. Insure the registered name on your system is the same as the one used in the related files and points to the .odb location on your system. In one of your comments you stated this was being used so you gave it a different name. If you do this you must change all the related files so they point to the different registered name. Pain. Better to just change your system to match these files.
At this point all should work.
It seems there are two things which should be of concern. Making sure the DB automatically adjusts its’ location when moved and that each system user has the same name for the registered DB. The actual location on each system can be different but the registered name is key here.