ArcGIS Archiving (Part 2)
In a previous post we took a deep dive into ArcGIS Archiving and found that it can offer some important benefits to utilities that may have a need to look back at what your database contained at a previous date and time. But there is more to Archiving than can be covered in a single post.
In this case study we’ll look at additional functionality offered by Archiving, as well as a few known limitations.
ALL Of the Edits
It may be the case that you feel there would be little or no benefit to implementation of Archiving because you’ve configured your versioned Geodatabase classes for edit tracking; either by means of the Esri Editor Tracking or by ArcFM meta-analysis auto-updaters. While the edit tracking does provide value, as we pointed out in our previous post, it knows nothing about deletes. What we didn’t mention before is that edit tracking also only informs you of the *last* edit performed — even if that edit was performed by a process such as a Feeder Manager update or other automated process.
Further, don’t necessarily turn off the editor tracking when you implement archiving. Archiving can tell you the *when* of an edit but not the *who*.
Archiving records and makes available for viewing all changes to all features posted to SDE.DEFAULT. Consider the following example. Below we see a gas valve from the “GasValve” feature class archive. When we do an “identify” we see that is was created by a user named BOULDER at 2:27 PM 2/1/2015.
Digging further we can see that a user named GAS edited the feature later the same day, updating the BONDEDINDICATOR field. Finally, a user named ELECTRIC edited the feature 26 minutes later updating the INSULATEDINDICATOR field. This is information you can’t get from edit tracking alone!
Archiving versus Database Backups
You may feel you don’t need Archiving because you do regular database backups. Don’t get us wrong, database backups are *very* important. Strike that, they’re vital.
But say you do backups nightly to restore to the previous day, and retain backups performed each week or each month. That still won’t help you answer the question, “how and when did that gas main get deleted?”, or the question, “how many times have we updated that pole because it was hit by a car?”, or the question, “was that device ever at a different location? And if so, where was it?”
OK, that’s not exactly true. You could theoretically reload all of the backups you’ve ever retained and through a LOT of detailed examination *possibly* answer those questions, but only possibly.
The point is that ArcGIS Archiving and backups are different things with different goals.
For a variety of reasons some companies want or need to track the number and type of edit performed by feature class, and in some cases by user. Once you’ve implemented Archiving that information is readily available — no customization required. Below is an old-school example of how you can get to counts of edits by user. In this case we can see that the user ELECTRIC performed edits on 142 individual features in the DISTRIBUTIONMAIN feature class on or after February 1st, 2015.
A Few Known Limitations
It’s not perfect. For example, it won’t pour you a beer after work. But that’s probably beyond reasonable expectation. Whether reasonable or not, here are a few other things it won’t do that you might (or might not) find helpful.
Loading past history
There aren’t many examples we know of where this might apply – but we know there are some. I the event you have some representation of edit history in some form, there’s no Esri approved way to load data into a feature class’ historical table. Who would care? Well, there are companies that retain edit histories in tables maintained by custom code. In some cases the tables simply track deletes, in other cases the tables track all edits. A company moving from a custom solution to the core product would certainly need to keep its existing history records.
Another case would be company migrating from another mapping system that was also aware of edit history and had populated history tables.
tracking after a given date While many companies want to know the chain of events that led up to their database looking the way it does, in some cases a company may want to apply a statute of limitations. After a period of, say seven years (or a period of your choice) a company may not be required to retain historical information. And since not required, the company may prefer not to have these records retained. As of this writing, there’s no way to truncate history beyond a given date.
In this case study we dug a little deeper into ArcGIS Archiving. Hopefully this has helped if you have any thoughts about implementing Archiving in your company.