Solution - Geodatabase Manager - Feeder Manager 2.0 Feeder Sync failures when posting 15+ versions at once

Version 1

    Behavior

     

    When performing a posting job with GDBM using Feeder Manager 2.0, and with the Feeder Sync option enabled, errors like the following may appear in the GDBM log if >15 versions, sessions, or designs are in the GDBM posting queue:

     

    2/10/2015 10:15:12 AM : Feeder Sync - Starting

    2/10/2015 10:15:13 AM : Feeder Sync - Edited Feature Count: 0

    2/10/2015 10:15:15 AM : Failed to synchronize FM1 fields. Reverting Feeder Sync

    2/10/2015 10:15:15 AM : Aborting Edit Operation during FeederSync

    2/10/2015 10:15:15 AM : Feeder Sync - Sync failed with message Failed to synchronize FM1 fields. Reverting Feeder Sync

    2/10/2015 10:15:15 AM : Feeder Sync - Completed unsuccessfully

     

    Cause

     

    This issue is the result of a known and fixed bug MM54569. This bug has been addressed in 10.2.1b.

     

    Solution

     

    If upgrading to 10.2.1b is not feasible, you can disable the use of the Esent database with Feeder Manager 2.0 for the Geodatabase Manager process. This is done by accessing the registry key HKEY_CURRENT_USER\Software\Miner and Miner\ArcFM8\Feeder Manager, and creating a new DWORD called EsentDisabled with a value of 1. If you are using the Local System account to run the Geodatabase Manager posting service (the default setting, altered in the Services list of Windows), you will instead create this key at HKEY_USERS\.DEFAULT\Software\Miner and Miner\ArcFM8\Feeder Manager. Feeder Manager 2.0 will still perform all the same calculations and your posted version will contain all the same information as they would without this setting. However, this setting will require holding the entire set of FM2.0 calculated values in-memory. But for very large geodatabases (state-wide or larger) with very large posting operations that span many feeders, this option may not be feasible within a 32-bit memory space. If you believe you could see a crash of the GDBM posting service by using this value, be sure to monitor the service after implementing the change.