Using ArcGIS Meta-Data Fields to Avoid Version Conflicts

Esri introduced “Editor Tracking” fields at release 10.1.   So they’re not really new, but if you’re not using them now you might consider changing since there can be a considerable positive impact.  When enabled they record the name of the user and the date any time a feature in the target class is created or edited, just like ArcFM Auto-Updaters.

Key things about “Editor Tracking” are:

1. They store the same information for user name and date created/date modified as the ArcFM AutoUpdaters, but
2. Unlike fields assigned the ArcFM Auto-updaters, they’re ignored (filtered) by the conflict resolution process

This second characteristic is really the key. It eliminates conflicts that many (probably most) users would prefer to avoid – those where the only difference is on either LASTUSER or DATEMODIFIED.

It really works, so if that’s enough for you to know then you can sign off here. One last thing though, the reason the meta-data Auto-Updaters still exist is that Schneider Electric kept them around for compatibility with prior releases.  If you choose to replace them, they’ll understand.

If you want to walk through the details, we can. In the rest of this post we’ll demonstrate.

Maintaining Meta-Data With “ArcFM User Name” and “ArcFM Current Date” Auto-Updaters

First step is to demonstrate how un-desired conflicts are created by the “ArcFM User Name” and/or “ArcFM Current Date” Auto-Updaters.   Here are the steps:

1. We’ll connect as a user “Test User 1” and create a version directly off SDE.DEFAULT named “User 1 Versoin” (sorry about the typo).
2. Then connect as a user “Test User 2” and create a second version also off SDE.DEFAULT named “User 2 Version”.
3. As “Test User 1” we’ll select a feature and update its FacilityID field.   The “Last User” and “Date Modified” fields are updated – by the ArcFM AutoUpdaters we had assigned to those fields.
4. We reconcile and post the version to SDE.DEFAULT to propagate our edit.



5. Now we open the second version and edit the “Work Order ID” field on the same feature. Again the “Last User” and “Date Modified” fields are updated.



6. Next step is to reconcile with SDE.DEFAULT. We choose the option to detect conflicts at the attribute level with conflicts to resolved, by default, in favor of the Target version.



7. As expected, we get a conflict on the “Last User” field. (We would have gotten a conflict on “Date Modified” as well, expect that both edits were performed on the same day.)

Maintaining Meta-Data With ArcGIS “Editor Tracking”

Now we’ll go through the same set of steps, except this time we’ll populate the “Last User” and “Date Modified” fields using the ArcGIS “Editor Tracking” function. So the two steps we need to follow are , A) remove the Auto-Updaters from the user and date fields (don’t forget this step), and B) enable Editor Tracking fields, which is done from the Class Properties field in ArcCatalog, as shown below.

Once the configuration change is made, we’ll walk through the same editing sequence. We can use the versions we had set up for the first test, “User 1 Versoin” and “User 2 Version”.

1. As user TESTUSER1 we connect to the version “User 1 Version” and update the FacilityID field of a feature. Now the “Last User” and “Date Modified” fields are updated by Editor Tracking”.
2. We then reconcile and post our edits to SDE.DEFAULT.



3. Then as TESTUSER2 we change the Work Order ID of the same feature, then reconcile with SDE.DEFAULT choosing the detect conflicts by attribute and resolve conflicts in favor of the target version. No conflicts! Actually, the conflict on “Last User” was filtered, and since we chose to resolve in favor of the target version the “Last User” field kept its value “TESTUSER1”.

Summary

Dealing with un-wanted conflicts can be one of the more trying aspects of maintaining an ArcGIS Geodatabase. At 10.1 Esri provided a viable mechanism to avoid them in some cases.   If you haven’t implemented this approach yet, its surely worth your time to consider.