What actions did you take immediately prior to getting this message?
Could this be a file produced by a progressive back up by FileMaker Server?
I followed the steps from a KB article from a link you sent yesterday.
1) Coped files from my documents folder to a folder in the root folder. 2) made restored copies using the same filename to a new folder, also in root. 3) Made cloned copies to yet another root folder. 4) exported data as a .tab file from the restored file, and imported it into the cloned file. 5) Copied the clone folder into the Root documents folder. 6) Opened that file, looked at the external data sources, and attempted to delete a source file no longer being used.
I don't have Filemaker Server. I have only opened the file on my Mac, or occasionally using Filemaker Go on an iPad. (The file was shared on the iPad, but hasn't been opened that way for several months).
Would that be the "what to do if your file is damaged" KB article?
I hate to say it, but that suggests that you may have a badly damaged file on your hands...
As my list of caveats on the recover process indicates, Recover cannot always successfully detect and correctly repair all possible types of damage that might occur in a file.
Yes, that's the one. I've done a lot of browsing over dealing with a damaged file, and found a bit of conflicting advice. At this point I'm trying to determine:
Is it indeed damaged? I suspect it is. It's been around a long time, on a lot of computers and seen all the computer mishaps. Are there ways to test the file, perhaps from a cloned empty state?
Is it possible that there are two separate problems? Is the "multiple hard link" error an indication of a sharing problem that can be repaired apart from the possible file corruption? Or is it all one big problem?
What to do? Is there any way to repair the file? I've seen that Filemaker and some 3rd parties offer file repair services at a somewhat steep price. How effective are they? Otherwise, do I need to steel myself to recreate the file from scratch using the original as a guide? The cost of a repair would certainly be better than the time involved in a recreation. Recreating the file has some benefits, though--the file has a lot of "legacy" showing my learning curve over the years, and where my requirements of the program have changed. A rewrite would certainly make the solution more trim, and probably a lot faster.
I appreciate your, and anyone else's, help in this.
If you cannot find a back up copy of this file that appears undamaged, you may have to try a rather drastic implementation of the classic "divide and conquer" algorithm.
Take a copy of the file, delete half of the structures in your file. Take a different copy and delete the opposite half. Test both copies for damage. If you are reasonably confident that one half of your file does not contain damaged components, make third copy where you remove only half the design elements that you removed the first time and test that half...
This can be a lot of work, but less work than rebuilding your entire file from a blank page.
You may also find that acquiring a copy of FMDIff may be a useful additional tool to use to check your file for damage.
Thanks for the help, Phil.
In the "divide and conquer" scenario, how are the two partial files tested for damage? My experiences with file crashing is that it is intermittent, unpredictable, and I can't trace it happening based on any particular activity.
FMDiff looks like it could be useful. I can't see how it can show where a file is damaged. It would seem it would require an uncorrupted file in order to see the corruption in the other. What don't I understand?
The assumption behind "divide and conquer" is that you have a reliable test that you can run on your file for damage--such as running a recover on the file and getting a result that tells you problems were found when the recover was ran. You don't actually use the recovered copy produced in this scenario, you just use it as a kind of "cat scan" of your database. FM DIff might be used in the same capacity.