[Tutorial] Recovering a damaged odb file

[r4zoli]

Power cut can cause data loss. The database part of an odb file sits in memory during edit process, and then is packed back into the file when the work is finished .

If your file opens in Writer and asks for coding selection, your file damaged. To restore it, you can try the following process.

Make a copy of your .odb file (to keep the original file) and change its extension to .zip.

If you can open the file with zipper program then there are some chances that you can retrieve your data.
If your file cannot open in zipper program, your data is probably lost.

When you open the file in the archive manager, you should see the following structure:

odb file structure.
(It is Hungarian version, but I hope you can match it to your system)

Go to the database folder, you should see these files:

Database folder.

database_folder.PNG (1.2 KiB) Viewed 32790 times

Extract the script and data files.

Open the script file, look for any discrepancies, and try to repair them.

Create new empty odb file, open it with an archive manager and overwrite the script and data files with the ones of the old file.

Close that new file and rename it back to .odb, you should now be able to work with it.

[r4zoli]

To be more clearer I describe the HSQLDB database engine work(it is derived from HSQLDB documentation).

A database folder can consists of between 2 to 5 files (what you can see my earlier post):

properties
script
log
data
backup

How HSQLDB works within odb file
The properties file contains a few settings about the database.
The script file contains the definition of tables and other database objects, plus the data for non-cached tables.
The log file contains recent changes to the database.
The data file contains the data for cached tables and the backup file is a compressed backup of the last known consistent state of the data file.
All these files are essential and should never be deleted. For some files, the data and backup files will not be present. In addition to those files, a HyperSQL database may link to any formatted text files, such as CSV lists, anywhere on the disk.

While the odb file is open, a log file is used to write the changes made to data. This file is removed at a normal SHUTDOWN during file closure. Otherwise (with abnormal shutdown) this file is used at the next startup to redo the changes. A lck file (not in database folder, but in a file system next to the odb file)is also used to record the fact that the database is open. This is deleted at a normal SHUTDOWN.

Note
When the engine closes the database at a shutdown, it creates temporary files with the name new which it then renames to those listed above. In some circumstances, a data.old is created and deleted afterwards. These files should not be deleted by the user. At the time of the next startup, file opening all such files will be deleted by the database engine.

[arfgh]

i cant understand how the db files get corrpted at unknown times, even with the last AOO version. Maybe the ones that work on it, just dont want that we have stable database files, or i dont know, but the problem is very well knows since YEARS !! what a shame.

[Villeroy]

i cant understand how the db files get corrpted at unknown times, even with the last AOO version. Maybe

Like any other huge file, a single database file gets corrupted when there is not enough time to write all data to disk. The additional wrapping of many files into one zip archive makes things even worse. With an external database you save every single record to disk (or to the server when running in network mode). Even if you kill the office by pulling the power plug, it is rather unlikely that an external database gets damaged, particularly when it resides on another computer.
Any database solution involving a single Base document requires a daily dose of well planned backup activity and a more conscious handling of your computer. There is a high risk of damage when you shut down the lid of your laptop, hibernate or shut down the system while an embedded database is loaded through a form or invisibly through the data source window. Depending on the database size, it may take several seconds to write all data to disk, close the connection and wrap all temporary files into the zip. A system shutdown immediately kills the office suite without warning. This is a thing that should not happen in 2018. There are mechanisms that allow applications to intercept a system shutdown.

[arfgh]

Villeroy, what i wanted to mean is, in my honest opinion, the database part of AOO should be more care. It is unaceptable to have the database in danger using this office suitte.

[RoryOF]

If you read Villeroy's posting, you will realise that the problem arises from improper user behaviour. Most problems with corrupt OO files, including corrupt databases, arise from improper User behaviour - to wit, over hasty close down of the computer, without allowing time for the files to be written fully to disk and the internal hard disk software buffers flushed to disk..

[Villeroy]

To be honest: It would be better if this container format would not exist. Before version 2, OpenOffice.org 1.x had the same database connectivity with almost the same features but without any "native database document". Connection data and query definitions were stored in the user profile, forms and reports used to be stand-alone Writer documents, all database tables where stored in their respective file formats. There are very good reasons why stable database backends are always separated from their frontends. Unfortunately, the crowd of 2004 cried for a "database document like MS Access has". Just a single file for local use by a single user. Now we have that and the same crowd tries to store it on networks, flash drives and access it from multiple places.

[arfgh]

again what i wanted to said is, for me AOO is a wonderful must have application in any computer. The most powerful feature on it is the Database part. For that reason, that part of the suitte should be more care. Actually and with the help of several this forums users like for example Mr. Villeroy, i performed some subroutines that operate on database starting in order to create automatically backups, because in the database using some years ago was totally 'nefasto', ending in all cases with a corrupt database files. The questions about split or embed db is not important in my opinion. The embed way is so confortable, but i feel several questions on that file that doesnt seems normal, like the expanding size and others....

Even with that weak point, i like so much the way that works the database part of the AOO suitte. Only need more cares from the ones that program on it....

[RoryOF]

The most care is needed from the User in leisurely closing down the files and then the computer; because of the complexity of the OO file formats, these take some few seconds more than a flat file, particularly since modern hard drives now buffer (= temporarily store) data internally before writing it to disk.

Any programming solution to cause file backup may increase the close-down time, which in turn could lead to even more complaints of corrupt files because of user impatience.

The few extra seconds needed to allow the hard disk buffers flush to disk will cumulatively be much less than the time and aggravation of trying to repair a damaged file.