Please upvote if you'd like this too.
I have a branch versioned featureclass that has accumulated a good bit of history - there are multiple features with the same ObjectID. (GDB_Archive_ID is unique.)
How can I delete all but the most recent features, i.e., the ones having a maximum GDB_FROM_DATE for each unique ObjectID?
Update: this blog from 2 years ago says :
Esri noted they are considering a prune task for a future release that would reduce the record counts in the base tables by combining older posted edits.
After doing so, I would expect there to be no repeating ObjectIDs. Currently all features have GDB_BRANCH_ID = 0.
I was expecting hoping to be able to do this with the Compress tool would do this. But it says:
This tool is not applicable for enterprise geodatabases that use branch versioning.
Besides, I'd really like a tool that compresses prunes just the feature class (or table) and not the entire geodatabase.
Would I break anything if a ran an SQL script that deleted all but the most recent rows?
The compress tool was only designed for this: by removing states not referenced by a version and redundant rows, within the delta tables, not the base table.
As I understand it with branch versioning was developed to have all the edits in the single table to allow different functionality than traditional versioning; Enterprise data management strategies—Geodatabases | ArcGIS Desktop , mainly WebGIS capability.
A few benefits:
Why do you want to get rid of the "old" records in the table?
Are you having performance issues with the data?
With branch versioning there are less queries being used to "display" the correct data than with traditional versioning.
Hi George -
Currently we're just evaluating Branch Versioning.
Here's a scenario: Say there's an organization that has policies prohibiting personal data in the geodatabase. Suppose, by accident, a social security number makes its way into the Customers table. The Manager tells the GIS admin "delete that immediately!"
If the geodatabase is branch versioned, how would the GIS Admin delete the row, or even just update the column in the "old" row?
That is a good question, I would think that we may need to get some sort of enhancement logged for this type of functionality. I can see a need for this.
I am not sure what the best way to do this now, I know that you could update the row manually in the RDBMS, but there may be other implications that I am not aware of.