How can I prune a Branch Versioned featureclass?

[Anonymous User]

Update: I've posted an idea here: https://community.esri.com/ideas/17459 

Please upvote if you'd like this too.

 ------------------------

Hi -

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?

Thanks, Kirk

[George_Thompson]

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:

• Enhanced editor tracking capabilities allow you to also track users who delete features within a version.
• Unlike traditional versioning, the compress operation is not required for geodatabases with branch versioned datasets.

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.

[Anonymous User]

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?

Thanks, Kirk

[George_Thompson]

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.

[Anonymous User]

Thanks George.  As suggested, I filed here: https://community.esri.com/ideas/17459 

[Anonymous User]

To be fair, Git has a hard time with this too.

Removing sensitive data from a repository - GitHub Help 

[RobertBorchert]

Have you tried stopping all services on the feature class and unregistering it as versioned and moving all to the base.

[TimStærkFendrich]

Hi,

3 years later 🙂 We are now using branch versioning along with the utility network model and we are experiencing performance problems.

The "Unregister as Versioned" process part of an upgrade of the utillity network model, cleaned out the 2 million rows in the dirty areas featureclass. And performance was much better. But scripts and daily use has created 200.000+ records in the dirty areas featueclass in a short time and we would like to prune the old records from the table in the DB. There is no need to store the history of dirty areas, but we would like to keep the history of all other edits in the utillity network.

So can we clean/reset just the one featureclass? Perhaps using SQL while we wait for a tool?

I checked the above mentioned idea but it is not implemented yet?

Thanks, Tim