The SEWERSUBNETLINE feature class is growing quite large within our eGDB. The branch-versioned feature service requires archiving to be turned on, so every time we update our "dirty" subnetworks, the previous subnetworks are kept indefinitely. The geoprocessing tools to remove archive records won't work on an eGDB feature class.
The SEWERSUBNETLINE currently holds 72 distinct subnetworks (in some cases with dozens of archived records). The table alone is now > 1.5GB in size.
Can we get some kind of tool or script that can "clean out" the archived records periodically (or even selectively)?
Solved! Go to Solution.
Hi @CarlVon_Stetten1 ,
This idea is currently under consideration. There are some workarounds that people have tried outlined in the idea, but they may not align with your business needs. Here is the link to the idea:
Trim Archive History Tool for Branch Versioned Data
Hi @CarlVon_Stetten1 ,
This idea is currently under consideration. There are some workarounds that people have tried outlined in the idea, but they may not align with your business needs. Here is the link to the idea:
Trim Archive History Tool for Branch Versioned Data
@CarlVon_Stetten1 if you are not interested in retaining history in your geodatabase (across ALL branch versioned classes) you can unregister your data as versioned to lose all history and outstanding versions.
One reason why your subnetwork line is so large is that you likely have included your laterals as asset types for your aggregated subnetwork line in your subnetwork definitions. This means that every time your update subnetworks you are creating a new copy of every main AND lateral in your system. I would advise you to only represent the mains in your subnetwork in your aggregated lines for both storage and performance reason. Including laterals in your subnetwork line makes the layer draw slowly, since you are having to draw every line in your system. Because you have a hierarchical network this means when you draw your subnetwork line layer you are effectively drawing every main and lateral in your database multiple times.
Trim Archive History request is long overdue. Unregister as versioned and reregister is not an option for some business needs. SubnetworkLine is purely a system maintained class with potentially very large multi-part geometry. It doesn't make sense it accumulates history.