The more important question is what practices led to the need to recover the file in the first place.
It just isn't something you should need to do, ever.
Files showing abnormal behavior in any way should always be examined for ways to recover them. The recover process is an option to repair internal problems to maintain the use of the file. I will have to disagree with never having to do that ever.... If you have worked with Filemaker for 10 years and never seen a file that needs recovery you are indeed lucky and unique...
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.
And here's a knowledgebase article that you may find useful: What to do when your file is corrupt (KB5421).
Did you file contain images? Just guessing from the name of the file.
To speak to the original question.
The internal structure of a FileMaker Database is a "black box" to us users.
The precise way that Recover scans and "fixes" a file for us is yet another "black box" into which we cannot see.
So, short of contacting a FileMaker tech and discussing this directly with them, there's not much any of us can offer to explain why it took so long.
While I do not have to recover files on any regular basis I begin with a compacted copy. If that works to gain access to the troubled data then I clone the file and import into the clone. When it does not, I recover the file. I then examine the relationships, menus, functions etc and make any necessary changes. Then it is time to clone and import. I had hoped for a look into the black box since the recovery was so abnormal. I once had to do this twice for a file until we discovered a bad hard drive. It never failed again.
Sorry for the late reply
My guess is that while the db file itself was very small, the external storage file ( or files ) may have been huge ( many GB )
Otherwise, please report this to Filemaker, as a possible bug
> The log shows over 68,000 lines ... What in the world could be taking 4 hours and create such a huge log.
The file has over 68,000 records with four text fields and an external referenced container.
What choice/option could I make to have it recover in less than 4 hours ?