Trim Archive History Tool for Branch Versioned Data

2583
9
05-07-2021 07:08 AM
Status: Under Consideration
Labels (1)
ScottNoldy
New Contributor III

To add another use case:

Feature class is versioned/archived/branch versioned simply to allow offline use in Collector.

Feature class is updated nightly from another database so every night, another row is added for each record to the dataset.  The dataset eventually grows extremely large killing performance.

Something similar to the Trim Archived feature class would be ideal.

Moderator Note

The below comments were moved from a separate Idea, to more accurately reflect the work under consideration by the development team.

9 Comments
premsweb

We have a similar issue with the dataset growing very large. It would be really great to be able to trim obsolete features. 

Another issue is that if you are trying to use SQL queries for geometries duplicates make it difficult to query the default geometry. 

 

Even some insight into the branch versioning geodatabase model to allow users to do this on their own would be very beneficial as an interim solution.

DrewDowling

Another up vote for this. Worried that parcel lines in the parcel fabric will grow to  tens of millions of records as we deal with fixing densified lines. A single cul-de-sac can produce hundreds of parcel lines when the build parcels tool is run. This is replicated across several parcel types. Even after the densified lines are converted to curves I'm worried that the hundreds/thousands of really short segments will stick around in perpetuity slowing queries and eating up space.

SSWoodward
Status changed to: Under Consideration
 
KeithMenia

I just go to this issue in our evolution. We use SQL Server as the back end DB. Traditional versioned DB starting to slow down? Just consolidate it. Worked great for the last 15 years. Branch Versioning is the only method being used by the Utility Networks and there's no way to get rid of old rows? That's totally unacceptable in my book. You can't tell me that all that edit history hanging around won't affect performance. Our DB's are growing at an exponential rate! Not to mention that any SQL drilling returns the garbage rows too (as was said above). 

Pretty sure I can make a view in SSMS to find the latest record on the base table, drop the garbage, but resolving the branches is harder.

Come on ESRI, I WANT to like Pro and the direction we're going, but they sure are making it harder than it needs to be.

 

AshParker1

Upvote.  Cleaning up is part of maintenance.

NickN
by

I just contacted ESRI about this because we manage a parcel fabric that nominally has 30,000 parcels in it. Well, almost 2 years of editing and running models to update attributes used in 3rd party integrations our fabric parcel table now has 7.9 million rows in it.

Support has this logged as ENH-000137295, which just celebrated it's 3rd birthday last week 😐, to allow the Trim Archive History tool to be run on branch versioned data.

Their recommendation to work around this limitation was to unregister as versioned then delete the records using the Trim Archive History tool, then re-register. Has anyone tried this workflow?

MarcWilkes

A customer of us used the unregister and then re-register workaround to reduce rows and it worked for them. They did not use the Trim Archive History tool, though.

lah
by

PLEASE add this!! We just "upgraded" to branch versioning from traditional versioning, since this is the supported model for our location referencing/APR tools. We have multiple models and scripts built that automate data loading for us from various forms every night. The Derive Event Measures tool, for example, doesn't work on feature selections, so as part of our general event loading workflow it must run on the entire table. This is duplicating every single record in the event tables every night. This is not sustainable, and I agree - a tool like this is a necessary part of database maintenance.

TorrinHultgren2

Agree that this situation is unsustainable. Why do the archive rows have to be stored in the same table? Wouldn't it be more practical all around to have the main table contain only the active rows, and have archive rows copied to a separate table? Would dramatically improve performance on the main table and make cleanup less disruptive.