Error in script file line, tables "missing"?

HSQL Database Engine 2.3.2 & LO Version: 6.2.5.2

I have a split dB that is stored on the cloud (Google Drive) and auto-syncs on save. It has been working flawlessly for weeks (since I split it) and I open/work with it almost daily.

Opening it up today, I get an “error in the script file line (path reference) 121” trying to open any query, form or report, and Base cannot load the tables list. Queries, forms, reports are listed. Forms will even preview, including the last forms I created yesterday.

Viewing the script file in an editor, I see that line 121 is a SET TABLE and refers to a table that was one of the originals that has never caused a problem. I also see that the .script file does not include any references to a new table created yesterday, but the .log file has references to edits done to that new table. The date stamp for the latest script version is accurate for my end-of-day save and matches the .odb stamp.

I have tried restoring earlier working versions of both the .odb and the .script file individually and together, even chucking all of yesterday’s versions and going back the previous day’s working versions. I tried deleting line 121 (I could recreate that table with some effort) but the error moved to another line reference. I tried restarting in safe mode

I cannot seem to get those tables back and they/the dB represent months of work. I know they are still “there” but I’m stumped how to fix this. Any thoughts or ideas on what to try next are desperately welcome as I’m out of them.

(I had not been very proactive about creating separate backups since G Drive keeps so many versions, which I have restored from before so I was cruising on a false sense of security. Silly rabbit.)

Hello,

As you now realize, depending upon use, a sync folder can cause problems with Base. Past experience answering questions results in copying the data from the sync folder into a local folder and back when done. Personally don’t rely on “cloud” services for my files.

As for your problem, can only offer suggestions. Anything can go wrong with the save process. The three files important to the database (tables if you will) are:

  • xxx.data ---------- actual data

  • xxx.properties – contains the information of the HSQL being used

  • xxx.script -------- details of the tables used

These work in concert with each other so replacing a .script file from a different version will still have problems.

Here is what I would try. Create a new empty split Base file. Then take your three database files and replace the newly created with a copy of these renaming if necessary. Open the Base file and see if tables available. If so, can copy from there to where desired. If not, try a different version. Remember all three should be from the same version.

Always work with a copy of files. Backup is key.

Thank you so much for replying. Even with the new Base file the same error persisted. So I decided to bite the bullet and tinker…with interesting results. (All this was done in a copy) I edited the script file to remove all SET TABLE lines and reopened the .odb file successfully with the table definitions & relationships present but empty of data. I put those lines back in and again opened it with no error, but still no data. So at least the painstaking relationship building is now recovered…maybe? The .data file still seems to contain data based on the file size, is there any way to get that data back into my table structure?

Have not much else to offer. Cannot determine what else to do without looking at the actual files. If there is no confidential/personal information post a copy of the files.

Also you seem to imply the process was done with current files. Have you tries a previous set of files with the mentioned process?

I managed to rebuild a workable version with a combination of removing any SET TABLE lines that referred to (suspected) corrupted data in the data file and rebuilding the missing tables data from versioned .log files. I cannot believe it but it worked. Thank you for taking the time to help, it is much appreciated.