I have read that this is due to an invalid index and I believe it. Sometimes (if you have one or two indexed fields) you can turn off the indexing and then turn it on again. That did not work for a situation for me similar to what you describe. What did work is to close the offending database, and then use the recover command to recover the file. Make sure you have the advanced option to rebuild the indexes checked when you do this.
Why this occurs, I do not know. After a few weeks of trying to fix this, this soluiton has fixed my problem and no reoccurances in about three weeks.
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 here in the Report an Issue section of the forum.
It can also be downloaded as a database file from: http://www.4shared.com/file/8orL8apk/FMP_Bugs.html
Many thanks to both dbail and PhilModJunk for your help. I will let you know what eventually works for me, and I'll be trying the Recover method first. I never actually use a recovered database in a solution, based on bad experiences long ago, but I wil recover and then transfer the recovered data set to a clean clone.
Thanks again -
When you use the recover method to re-index fields as specified in that thread, it should be safe to use as there are no other changes being made to the file. If you are going to import into another file, there's no need to do the recover with these settings as importing the data also rebuilds all the indexes.