IM 5.8.4: database error

[Carlo Didier]

As my vital scripts don't run anymore in iMatch 2017, I'm switching back to 5.8.4.

Problem: I re-installed 5.8.4 and restored my db from before converting it to the 2017 format. But when I try to open it, I get the attached error.
iMatch installed as administrator and run once as administrator. Get the same error with the database as normal user or as admin. File and folder permissions are ok.

[Mario]

Check the IMatch log file. It will contain additional details.
Maybe the restore was faulty and the database file is physically corrupted? Did you try to restore again?

[Carlo Didier]

Log files attached. One for trying to open the db and one for trying to repair it (apparently nothing happens when I try that!)
I restored sevral versions from different dates. None works. Tried restores of another (smaller) db and they all open fine.

[Mario]

The database system reports:

Physical database damage: 'database disk image is malformed'

This is an error we sometimes see when IMatch was writing to a database during  power failure or when Windows involuntarily shuts down without a chance to flush the disk cache to the actual physical disk.

This is not good. Such errors are unrecoverable and only a working backup copy of the database can help.

Pack and Go has been designed to prevent exactly this. Unless you disable the option, Pack & Go instructs the database system to perform a full diagnosis of the database file. Only when the database system reports no error, Pack & Go adds the database to the package. Else it stops.

[Carlo Didier]

I saw that in the log file, but I can't believe it.

This would mean that I always crashed iMatch with the database (which is on an SSD drive) for months (as I tried restores from a number of different backups)! Which I didn't do!
And I always ran the backup only with iMatch closed. There were never errors in the database diagnostics.

[Mario]

IMatch crashing will not damage the database.
A physical database damage can only happen when the database system writes data to the disk. Windows receives the data and acknowledges it as written. The database system then updates it internal state. But while the just written data is still somewhere in the Windows file cache, the system fails, powers down etc. Windows can never write the data to the actual disk and this damages the database file.

Unless a regular diagnosis is performed, such problems can go unnoticed for a long time - if the damage is in a rarely used part of the database file. The diagnosis uses routines provided by the database system to detect such problems. If the diagnosis reports OK, there should be no physical database damage. Unless the diagnosis is faulty. But the database system used by IMatch is one of the best tested software products around, and also used by Google, Apple, Adobe, Microsoft and Boing.

The procedure describes above is the only known way to physically damage a database I know of. I use this database software for over 10 years now in IMatch and other products.

[Carlo Didier]

Found it!
The culprit is Macrium Reflect (one of my backup tools). If I mount a backup as a virtual drive to retrieve a file, there is a problem with files bigger than 4GB. They are split (due to FAT32 restrictions).
Restores from other backups (done through synced copy or with Crashplan) were ok. Also, when I use the file restore with Macrium withoiut going through the virtual disk mount, it works too.
Phew, I really had doubts about my Macrium backups ... (although I have three other backup systems to go to for a restore).

[Mario]

Good news!