Better “diagnostic recovery” (defined below) options

Idea created by TonyWhite on Nov 2, 2015

    Based on the template here: Product Ideas Product Ideas

    A summary of your idea:
    Better “diagnostic recovery” (defined below) options

    1. Faster (and therefore better) diagnostic recovery when run manually using FileMaker Pro Advanced: Currently a diagnostic recovery can be run manually, or in an automated workflow using the associated script step. When running a diagnostic recovery manually, there is an option available to turn off indexing. When using a scripted process, the ability to turn off indexing is NOT available. The ability to turn off indexing when running a scripted recovery would be faster, and therefore more useful. (Creating an index has a cost in the form of time, and often has no benefit.)
    2. The ability to run a diagnostic recovery as a server-side schedule: This would provide an early, automated warning when the integrity of the file is compromised internal to the block structure.


    One of the most important aspects of FileMaker development is monitoring and maintaining file integrity. FileMaker does a good job of maintaining FileMaker file integrity, and over the years has added a number of tools for monitoring and detecting when something goes awry. (There are many reasons why a file might start acting badly, from a bad sector on a hard drive to an electromagnetic pulse flipping bits on the hard drive.)

    There are a variety of different tests that can be performed to diagnose, and in some cases, repair an incorrectly performing file.

    At the risk of over simplifying, it can be said that the FileMaker file structure has two primary levels...the blocks and the contents of the blocks. Issues can occur on one of both of these levels.

    Each of the following tests is important. Experience has shown that a file might pass all of the tests but one. Here are what we consider to be the 4 most important tests:

    1. Run a FileMaker built-in verify command in order to check the block structure (from FMS)
    2. Run a “diagnostic recovery” FMPA > Menu > File > Recover... > double click file > Use Advanced Options > read log, but do not use file (provides additional information about structures that are internal to blocks)
    3. Run a DDR to determine if the DDR can be produced without crashing, and that the DDR XML is valid
    4. Use the third-party FMDiff tool, which runs very rapidly and provides additional information about FileMaker files

    Experience has shown that a file can pass the verify command (test #1) and still show issues when a diagnostic recovery (test #2) is run.

    There is a separate product idea to run a DDR in an automated fashion from FMS Automatically Generate DDR. This would be useful. I would add that the automatic running of a DDR should also validate the DDR, and if the XML does not validate, that information should be fed into the FMS email notification system.

    Why this idea is important to you:
    I want to monitor and protect my clients FileMaker investments in the most efficient and effective ways.

    Specific use cases you are looking to solve:
    Proactively keep our clients safe and maximize their happiness with the FileMaker platform. These product ideas apply in almost every use case.