6 Replies Latest reply on Aug 28, 2015 8:49 AM by Ed Blair

    MM_EDITED_FEATURES Table

    Ed Blair

       

      Hello –

      I’m trying to understand a little more detail about how the MM_EDITED_FEATURES table is managed and used. I understand that in general the table is used by Feeder Manager 2.0 to track features edited per version and is used to drive how the FeederSync process operates once a version is posted.

       

      Where I’ve gotten a little confused is that, in a test environment I dropped all relationships, dropped all versions and un-versioned the database.  I had expected that since the table is un-versioned and appears to have no relationships, rows would remain present in the table.  But not so.  After my steps the table was completely empty.  This may be what *should* be expected, but I’m not quite sure why.

      If anyone has more information on this it would be much appreciated.

       

      Ed

       

        • Re: MM_EDITED_FEATURES Table
          Ed Blair

          All –

           

          After looking at this a little more I *think* I understand what happened.  Feeder Manager 2.0 implementation assigns an AutoUpdater named ‘ArcFM Feeder Cache Maintenance’ that seems to be responsible for writing to and reading from the MM_EDITED_FEATURES table.   In my case, though I had dropped relationships, deleted versions and un-versioned the database my feature classes were still ArcFM-ified when the versions were deleted.   I’m guess that on the version delete this AutoUpdater fired and removed rows from the MM_EDITED_FEATURES table – which is what one would expect to happen.

           

          Will probably do a little testing of this hypothesis.  Am hoping that’s what happened, because it would make sense – and life is always a little easier when things make sense.

           

          Ed

           

            • Re: MM_EDITED_FEATURES Table

              When we've dropped / deleted all the versions in our database we have experienced the exact opposite, the table remains populated.  The table is written whenever a users saves their changes after modifying features managed by FM2 (the feeder cache maintenance AU may flag the features as being dirty, but no edits are written out until the user saves).  The only code I know of that reads this table is the feeder sync code that Schneider providess (they have one version in GDBM, I'm not sure what other versions they provide).  There is also a feeder sync cleanup process (again, I'm only familiar with the GDBM version).

                • Re: MM_EDITED_FEATURES Table
                  Chris Boesl

                  As a follow-up to Robert's comment, we are also seeing the opposite occur with a little bit of a twist.  We are seeing records being written to the MM_EDITED_FEATURES table when DELETING a session that has never been saved.  Example:

                   

                  1. Enter new session.

                  2. Place a dozen new features

                  3. Delete the session using the Delete Session command on the ArcFM toolbar in ArcMap (Never been saved)

                  4. Review the MM_EDITED_FEATURES table.  There are records for every one of the new features placed even though the session was deleted and never saved.

                    • Re: MM_EDITED_FEATURES Table
                      Ed Blair

                      Chris -

                       

                      Thanks for the info.   Out of curiosity did you find this using 10.2.1a or 10.2.1b?  My understanding was that there should be many fewer records in MM_EDITED_FEATURES with the 10.2.1b release.

                       

                      Ed

                        • Re: MM_EDITED_FEATURES Table
                          Chris Boesl

                          Hi Ed,

                           

                          Found it with 10.2.1b.  According to support, this works as designed.  When the user performs the Delete Session operation, part of the Delete is to perform a Save operation first.  The Save portion of the Delete creates the MM_EDITED_FEATURES records and they are left following the Delete.  The OVCT then will clean them up.  Not sure why it isn't also part of the Delete to clean those records out, but it wasn't designed to work that way.