The problem with using a recovered file is that it can be difficult to be sure that the recover process didn't "fix" the file in an undesirable way. It would be a real problem if a few months down the road you discovered that a seldom used but critical portion of your database was missing and had to be recreated from scratch.
With such a file that has been recovered a second time after a "do not use" result is a good candidate for having hidden changes to your file.
But there's also a known bug in FileMaker 11 (Seems to be fixed in FMP 12), that can produce a spurious "do not use result" when in fact there is nothing wrong with your file.
You can check for this if you do the following:
Find and delete the recover log. THis is not absolutely necessary but makes it easier to know that the log entries you are reading are from the most recent recover and not a previous recover as Recover keeps appending to the log file each time you do it.
Take a copy of your unrecovered file and recover it. Dismiss the do not use message and open the log file. Look for any references to a layout being changed and make a note of each such layout where such a result was logged.
Take yet another copy of your file and on each layout where it was logged in the recover log with such an entry, enter layout mode, select all objects and select "Ungroup" from the layout menu or the inspector. Every button so ungrouped will be broken by this but that's OK as this is just a test with a copy of the file. Click OK for each such warning about ungrouping a button.
Now recover this modifiied copy.
If you no longer get the error message, this is a case of the "groups with different alignment recover bug" and your original, unrecovered file is OK to use.
For More Information see: FMPA 10: group graphic + align = corrupt file?
This is one of many acknowledged bugs that can be found in the Known Bug List thread here in the Report an Issue section of the forum.
It can also be downloaded as a database file from: https://www.dropbox.com/s/jt09b82i0xijbu3/FMP%20Bugs.zip
Things to keep in mind about Recover:
While Recover almost always detects and fully corrects any problems with your file...
- The recovered copy may behave differently even if recover reports "no problems found".
- Recover does not detect all problems
- Recover doesn't always fix all problems correctly
- Best Practice is to never put a recovered copy back into regular use or development. Instead, replace the damaged file with an undamaged back up copy if this is at all possible. You may have to save a clone of the back up copy and import all data from your recovered copy to get a working copy with the most up to date information possible.
PhilModJunk Thanks for the expansive response. Most excellent. Followed your instructions, sure enough the issue found by using "Recovery" was a grouping of objects in several layouts. The issue goes away after ungrouping all. Therefore, not a real issue, my database is safe. Thanks again. Someday "Recovery" may become a really safe process.