The recovery does not always remove corrupt records. I would make a backup first then manually delete the record. This is also a good time to implement a daily backup system if you haven't already.
Did you check the recovered copy to see if the "mystery record" was still there. Recover rebuilds all your field indexes and this normally corrects this issue, but it does not check the indexes for problems, it just rebuilds them so nothing gets reported back to you as having been found and fixed.
For More Information see: Phantom Record, damaged file message, Recover can't detect a problem
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
If the recovered copy doesn't have this mystery record, you can try another recover but use FileMaker's advanced recovery options to only rebuild the indexes and not attempt any other repairs to your file:
If you have FileMaker 11 or newer, you can use Advanced Recovery options to rebuild your file's indexes:
- With the file closed, select Recover from the File Menu.
- Select "Use advanced Options"
- Select only: "Copy File Blocks as-is" and "Rebuild Field Indexes Now".
In response to Phil, no, the record doesn't appear to be in the recovered file.
To S Chamblee: is manually deleting the record enough? Is there larger corruption that this is a mere symptom of, and deleting the record doesn't fix anything? Does doing a recovery actually fix whatever corruption this might be?
I will take a look at those references, Phil and David. Thanks!
You will not be able to delete this record as it does not exist. But rebuilding the indexes will correct the problem and make it disappear.
It is not recommend to use recovered files, but sometime you have no choice if you don't have a backup.
In my opinion, a recovered file produced with advanced recovery options that only rebuild the field indexes and that "copy blocks as is" should be quite safe to put back into use. This is the one exception I make to the "don't use recovered files" rule.
Well, it didn't complain when I deleted the record. It appeared to delete it. And closing and reopening the file still showed the record as being gone. However, when I did a recovery on the file (no advanced options selected, which I believe implies it does everything), the log file still showed that it had adjusted the index, but nothing was listed in the summary or as a warning, error, etc.
I did a manual rebuild (turned indexing off for the offending field, closed the file, went back in and turned it on). A recovery done on that file (with just the block-copy and index rebuild options selected), showed that there was no index adjustment that was made on that field.
So...what does it all mean? Do I have to worry about using this file, assuming that I go through and manually fix it?
The recovery process, if it doesn't adjust anything at least, mentions that it is OK to use the recovered file moving ahead. Still not recommended?
It's due to the fact that a full on recover may have made changes that are difficult to impossible to check and confirm that they were the correct changes to repair your file. There's no way to be abolutely sure.
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.
I make an exception in this one case, because the only things modified are the indexes. "Copy blocks as is" means that the structure of your database should not be modified in any way by the recover process. Essentially, this should be the same thing as saving a clone of your file and then re-importing all your data--the way we used to rebuild all indexes in a file in versions of FileMaker older than Filemaker 10.