The good news is that, using SQLite et al, I was able to recover something like 99.9% of his 9559 person database (pending his visual inspection that it looks right) to a fresh database. All the persons came across - what I have identified (so far) as lost are 2 or 3 links to image files (out of some 2900) and 8 or so events (out of some 15000). I suspect there could be more but intimate knowledge of the data is required in order to detect it (Emil's eyes needed for that job).
The bad news is:
- We don't know how or when the database was corrupted.
- The error message only shows up when a RM4 process causes the SQLite database engine to access an area of the database that is corrupted. Corruption can exist undetected over months of database building and editing.
- The RM4 backup procedure does not use SQLite; it is merely a file compression utility that faithfully preserves database corruption.
- Running File > Properties is not a sufficient test for corruption as that procedure does not use all database tables and indexes.
- Running a full GEDCOM export of everyone in the database is a more relevant test for corruption. If it does not complete, the database is certainly corrupted.
- Unfortunately, a complete GEDCOM export by itself does not assure that it will be imported without corruption. That can only be determined by importing it to a new database and inspecting and exercising the latter in a variety of ways.
- Regular GEDCOM export could be an alternative backup procedure that would exercise the database in the most critical areas, were it not so inconvenient and were the import not so susceptible to corruption.
- RootsMagic Support appears not to have one or more of tools, skills and inclination to attempt database recovery.