Trim Archive History Tool for Branch Versioned Data

[ScottNoldy]

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.

[ScottNoldy]

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

[dj]

+1 from another developer concerned about database bloat.

[WillBooth2]

The Utility Network implementation I help look after has only been live for about six months and the rows in the branch tables for the subnetline feature classes are already over 100 times the number you see in DEFAULT.  This matters a lot as the doing spatial intersects on these are very inefficient due to the subnetwork line extents (a SQL optimiser issue), which makes their map display and using the Find Subnetworks tool incredibly slow.
Also DIRTYAREAS already has over 400,000 rows compared to the ones needing attention in DEFAULT will be well less than 100.
I can't see a useful business case for keeping history for these feature classes in particular for the life of this implementation.
Being able to periodically trim this these will be a necessity sooner rather than later.

[Kevin_MacLeod]

Hi folks, anyone know if this is implemented yet?

I am at a cross-roads and want to get a handle on a lot of field data coming in. We are at SDE/Enterprise 10.9.1 and updating imminently.  Branched is the "future" but without simple ability to clean up I am hesitant. I see the workarounds above but I do not have time to experiment or use unsupported things that may or may not continue to work.  

Esri team- any updates? Will this be officially implemented at 11.3.x or 11.4?

[SSWoodward]

@Kevin_MacLeod This idea is still under consideration and has not been implemented.  I'll be sure to update this idea when more information is available. 

[BogdanHristozov]

Hello,

I don't see any benefits of having the archive records stored in the base table. Over time, the amount of  archive records would significantly increase. This can cause troubles in backup management decisions and performance. There was a comment about copying the archiving records into a separate table, which sounds more relevant - the archive records should be separated from the current state of edits and to be used only in designated workflows.