ArcGIS Archiving (Part 3)

In two previous posts we first explored the business value offered by Esri’s ArcGIS Geodatabase Archiving capability and second explored some of the details on how the technology works and ways your organization might benefit from it. Information in these posts was based on our own internal “clinical” testing plus feedback from a small number of utilities that are actually using the technology in their production environments.

In this post we feel compelled to offer a note of caution. Not because the technology doesn’t work as advertised or because, under normal conditions, it won’t provide a long term safe guard you’d be hard-pressed to get any other way. The note of caution is about what could potentially occur under abnormal conditions.

Here are example scenarios of potential concern.

Basic Disable and Re-Enable Archiving

If you disable archiving and subsequently re-enable it, the new archive tables will be empty and have no knowledge of your past history. And there is no officially supported way to get the old history re-connected with your Geodatabase classes.

Now, disabling Archiving doesn’t necessarily *delete* the old archive tables. New ones are created with a different name. So, an unofficial approach would be to use simple SQL to copy rows from the original history table(s) into the new ones. And this would be OK (given a LOT of care and testing) as long as you’re not using a binary geometry type. The binary geometries are stored in “F” and “S” tables which would also need to be updated – which much more care and testing.

Complex Disable and Re-Enable Archiving

Our first scenario ignores the fundamental question, why would I disable archiving in the first place? Which falls along the same lines of, why would I un-version my Geodatabase. Well, you wouldn’t normally. You wouldn’t even do this in a somewhat abnormal circumstance – it would have to be a *really* abnormal circumstance. Here’s an example.

First, say you need to perform some significant maintenance activity on your versioned Geodatabase. One that requires removing all versions. The maintenance would have to be something like rebuilding your geometric network or converting all features to a new projection or some other enterprise impactful activity.

Second, say you have a large number of versions in your Geodatabase that you can’t reconcile with SDE.DEFAULT, post and delete. Even if you need to perform the first step, if you can post all outstanding versions with SDE.DEFAULT – or delete some versions and post the rest – you’ll be OK as far as Archiving goes.

Third, you try plan address the required maintenance activity by moving data from versions into a temporary data store and then re-creating the versions and the data after your maintenance activity is complete.

As stated, a pretty unusual set of circumstances, but it could happen. And has.

Anyway, the problem here is that Archiving makes use of ObjectID values to associate business table rows with history table rows. In the scenario above when you re-create features into the re-created versions then the new features get new OIDs – and you’ve lost connection with the original feature. In this case, when we go to re-enable archiving in addition to moving rows from the old archive table to the new one, we also would need to switch out the old OBJECTID in the history table with the OBJECTID of the newly re-created feature. This is not impossible, but we’re approaching rocket science.

Geometric Network Operations in Historical Versions

We have not seen this. Quite the opposite, our testing has included geometric network tracing on historical versions. We can’t even give you an exact set of steps that would cause a problem, but in the interest of full disclosure it’s our understanding that under some circumstances if you perform a trace on a historical version (one that includes a reference to the “H” table) you might not get the expected results.

Since traces on your normal, non-historical versions (like any other query on a non-historical version) don’t touch the “H” tables these would not be impacted.

Summary

At the end of the day the message of this post is that, first, Archiving gives you information about how your database was updated you get in no other was from core ArcGIS technology. However, second, if you proceed down this path its best to do so with some caution.

Finally, as we’ve mentioned in the course of our Archiving discussions, there is at least one third party solution that addresses much of the functionality provided by Archiving. That being the All Edits Reporting and QA tool by SSP Innovations.