I have a database that I regularly perform a recovery on - just to ensure its integrity. I have NEVER used the recovered database - only used the recover command to monitor integrity. Recently the interface file produced errors when a recovery was performed with a message that the file should no longer be used going forward. After extensive testing and analysis of the recovery.log it appears that whenever all the objects on a layout are moved a few(4) layout objects raise errors. Even only moving a subset of objects can raise the issue - but selecting all is the acid test. I can then recover the RECOVERED database and no errors will be flagged. If I then repeat the process (move some objects) in the RECOVERED database it will then fail a subsequent recovery! I went back to some backups creating 2 months ago and they exhibited the same issue - and they all passed periodic recovery tests at the time. This is a very worrying situation - effectively there is no way of reliably testing the integrity of a FM file. I did all the right things - backups - recovery tests - and still got ambushed. Not a system robust enough to warrant months of development I would have thought!

This issue has been discussed and documented for some time. It is a false positive caused by rounding errors in pixel alignments of *grouped* objects. I believe we can forgive the FMI engineers for this, and it does not render an otherwise fine development environment completely useless.

Have you not discovered the Check Consistency option in the Recover dialog? It may save you time not having to recover the files.

Note that the Recover command has undergone some significant changes since version 9 and it continues to be improved.

Vaughan - Don't know what you mean by false/positive - are you saying the recovery.log is not accurate when it displays info like >

0 Recovering: layout 'MAIL' (24)

8475 Rebuilt group with 5 object(s)

8475 Rebuilt group with 4 object(s)

8487 Reset table view

8476 This item changed

Check Consistency doesn't flag any errors > are you saying that this is more accurate than the Recovery Log?

(This is FMPA 11)

I mean that the "corruption" caused by the rounding error in grouped objects is known, has been well discussed and is a false-positive sign of corruption.