3 Replies Latest reply on Mar 20, 2009 8:29 AM by Ward

    FMP 10 Recover trashes a working file



      FMP 10 Recover trashes a working file

      Description of the issue

      As I mentioned in the another thread (FMP 10 Design Report "Missing" fields and layouts aren't really missing), many of my DDR reports include phantom errors.  Since the FM files have evolved over a number of years, I thought it might help to clean up the files using Recover. However, Recover seems quite unhappy with the "Structure" of the first (smallest) file I tried. WARNING: problem were detected while recovering the database. ... The recovered file should NOT be used going forward; ... Recovery results:Structure: scanned; 115 items modified. I've scanned the Recover.log, as recommended.  Some lines are clearly informational; others report problems; and many seem unclear. I produced DDR HTML reports for the original and "recovered" files to see what they reveal.  Using BBEdit's Find Difference to compare the HTML files was enlightening. For example, Recover.log: Recovering: field 'Category1' (48)Changed the default options for number formattingCalculation modifiedThis item changed HTML: The Auto-Enter calculation is missing in the recovered file. Recovering: field 'Item IDs' (469)Reset field formattingCalculation modifiedThis item changed HTML: The Calculation has been completely trashed: TrimTrailingValues ( List8])Hour(Greek Here's the original calculation:TrimTrailingValues ( List8 ( Items::Item ID1 ; Items::Item ID2 ; Items::Item ID3 ; Items::Item ID4 ; Items::Item ID5 ; Items::Item ID6 ; Items::Item ID7 ; Items::Item ID8 ) ) (TrimTrialingValues and List8 are two of my custom functions.) It's not clear whether my file is truly corrupted, whether Recover is getting tripped up by whatever is confusing DDR, or something else entirely. It is clear that Recover is making a mess of my file ... and leaving me worried about what to do. I'll happily provide a copy of the file if it will help the FM development team improve Recover. -- Ward

        • 1. Re: FMP 10 Recover trashes a working file

          I've experienced this myself, but must caution that your analysis may be in error. It's entirely possible to have a file that appears to function normally for a very long time yet it can harbor hidden problems. Then you perform the recover and recover gives you a report similar to this.


          Keep in mind that Recover's primary focus is to salvage a damaged file sufficiently that you can open an undamaged clone of the file and import your records into your file. It'll try to avoid damaging the file's structure but there are no guarantees.


          Those of us that have been using Filemaker for many years appreciate the fact that we now have a recover log and the warning message you quote. There was a time when you didn't get nearly so much info when you ran a recover.


          A good "safe" practice is to always move your data out of your recovered file into a backup clone even if the recovered file appears to work normally.

          • 2. Re: FMP 10 Recover trashes a working file



            Thank you for your post.


            The information by "PhilModJunk" is correct (Thank you!).  However, there was a report recently that several custom functions show errors in the Recover log.  If the internal ID's are 16, 17, 20,21, 22, 23 and 29, an error will show.  To see the complete details, go to:




            That may or may not apply in your case, but I thought it would be worth mentioning.



            FileMaker, Inc.

            • 3. Re: FMP 10 Recover trashes a working file

              I've used Recover a number of times over the years in response to FileMaker reporting a corrupted file at open time.  I had always considered Recover to be a general database repair tool, cleaning up both structure and data.  Since structural repair is apparently not a focus of Recover, in the future I'll use it as described by PhilModJunk to recover data.


              As you can see from my earlier note, in this case I was trying to use Recover to rebuild the structure of my database.  The handful of data records are of no consequence because the database is the foundation for solutions I create for my clients.  It's the table definitions, custom functions, layouts, value lists, etc. that are important.


              Although I have direct indication that the structure of my database is corrupted, DDR's phantom "<missing>" warnings have been a nagging concern.


              I've reviewed the Bad file structure caused by Custom Functions (also with NEW files). thread that TSGal identified.  It does seem to describe what I'm seeing with my production database.  My Recover log reports changes to dozens of my custom functions.


              I'll be tracking the progress of that other thread.


              -- Ward