It would be nice to have the capability to re associate archive tables after a database has been unversioned. Currently, I need to back up this history every time I take my system completely down, which happens once per year every year, so basically I have a File GDB with all of this history. It would be nice to not have to take the data out and just reconnect it back to the FCs once my schema changes have been completed.
Currently, when you disable archiving in SDE, you can choose to save the history table as a new feature class. However, there is no way to re-attached that saved history table when you re-enable archiving. This is a problem when you need to briefly turn off archiving to make changes to the layer or to copy it from one database to the other. If there was a tool to re-attach the archive table to the feature class, it would allow for a more complete archive history. This could cause a "false gap" in the history if edits were made during the time archiving was turned off, but the DBA should still be given the option.
An additional option to this solution would be to allow the user to attach multiple archiving table. This way the DBA could save off each year as a new archive table but still be able to attach them as needed. In this case, the tables would be attached to the historical version tree but the records would not be imported into active archive table.
This is a similar idea to the following posts:
https://community.esri.com/ideas/2650
Keeping a true history of an asset's history would require that the information be located in one spot and not across several standalone tables. Administrators will inevitably have to turn off archiving and unregister data as versioned in order to do maintenance.
This feature would help to make a GIS database more of a true asset register.
Hi,
We have various geodatabases that need to be saved. To do this, Arcmap has a built-in functionality called Archiving. This is very good functionality as long as we don't have to make major changes to the system, such as adding layers, tables, topology, and so on. In order for the changes described above to take effect, archiving must be turned off and choosing to keep the archiving tables will remain at the database level, with no real connection. However, if we turn it back on, new tables will be created and will no longer be merged with existing ones. I've seen workrounds in various forums, but because we have a constantly evolving geodatabase structure, all solutions are very time consuming and can break things down in the wrong order. For example:
https://gdbgeek.wordpress.com/2011/11/22/restoring-geodatabase-history/
Perhaps there are more sensible ways for such a workflow to make all bigger changes and reconnect old archiving data in less time. Maybe create an additional option in Archiving to merge with existing tables? I know that I am not only who struggles with this problem.
Thank you!
BR,
Tiina Arras
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.