1 Reply Latest reply on Dec 14, 2016 11:20 AM by AllegroDataSolutions

    Recover command giving false positive results


      I have found at least one instance where the Recover command in FileMaker 15 was run on a file and reported no problems, only to find that a subsequent Recover on the same file (not a copy, and not the recovered file) reported two unspecified errors that were severe enough to warrant a warning not to use the second recovered file.


      I was having issues prior to running Recover the second time. Specifically, I found that finding duplicate records and updating records with an import using match fields were producing unpredictable results and then ceased working entirely. I ran Recover on the file and when it reported errors, I went back and re-Recovered the original (which it previously determined was uncorrupted). At that point, it found the same issues with the original file (which had been behaving normally when I worked on it.)


      The client had worked on this file in layout mode while it was hosted on a shared WAN server, adding and modifying fields, layouts, and scripts. So there were opportunities for corruption to occur before the file reached me. That was what prompted me to Recover the file to determine whether to modify the original or rebuild it from scratch.


      FileMaker 15 has not been updated since the first and second scans of the original file, so I have to conclude that the first Recovery (which reported no problems) was a false positive. In this case, that false result rendered all my subsequent work on the file to date useless (at a cost of over $4,000 to my client). A very frustrating and costly expense for all concerned.

        • 1. Re: Recover command giving false positive results

          Based on the instructions I received from FM Tech Support, I was able to find the items modified. It's a very long file. The summary described 2 items "modified", but doesn't say what they are. The log shows quite a few "changes" to several themes. I believe the solution uses a modified of only one of those themes.


          If only the themes are damaged, it seems to me that the problems with this file could be easily corrected by using a different theme. Hard to understand why this would cause the Recover command to conclude that the file should not be used, given the time and cost of rebuilding everything since the last build I worked on last spring. Or why I should get two different results on whether there was any damage at all when running Recover a second time a month later.


          I don't expect this feature to be perfect. Though I do expect it to be accurate and consistent.