Community
Select to view content in your preferred language

Using Python to batch edit attributes in a branch versioned feature class or table

245
7
Jump to solution
Thursday
AmyRoust
by
Frequent Contributor
Thursday

I've already got an Esri support ticket in on this, but thought I'd touch base with the hive mind...

I've got a branch versioned line feature class that I regularly update with information about inspections (I'm oversimplifying here, but stick with me.) Every night, a Python script accesses the published editing service, selects the affected lines, and updates a field with the new data from the most recent inspection. Very simple, right? Select by attributes and field calc.

Over time, these scripts have gotten slower and slower, to the point where what once took a few minutes now takes hours to complete. So I did a little digging. Last night, I decided to open the line feature class attribute table in SQL Server Management Studio so that I could see the hidden fields that are used by branch versioning.

If you look at the feature class in Pro, there are 23,099 lines.

In SSMS, there are 1,891,728 rows in the table!

My theory is that using Python to batch update on Default is somehow failing to trigger the "trim" functionality built into branch versioning and that all of those edits are building up over time even though I don't see them in Pro.

Has anyone else seen similar behavior?

 

0 Kudos
1 Solution

Accepted Solutions
DavidSolari
by MVP Regular Contributor
MVP Regular Contributor
Thursday

Updates to DEFAULT (either direct or via a version post) always archive the previous record, regardless of editing method. This is 100% by design. If you don't need the old data, fire up Prune Branch History and watch as your data springs to life. Since you're using Python, try adding checks to see which records actually need updates and consolidate updates to just once per row where possible, this will reduce unnecessary archiving and speed up your processes in general (assuming your process is I/O limited, which it almost always is).

View solution in original post

7 Replies
MichaelVolz
by
Esteemed Contributor
Thursday

Have to tried a compress on the geodatabase to see if that would help?

0 Kudos
DavidSolari
by MVP Regular Contributor
MVP Regular Contributor
Thursday

Branch versioned data only uses a single table so Compress has no effect, although if there's also traditionally versioned data in the same database it might improve overall performance.

0 Kudos
DavidSolari
by MVP Regular Contributor
MVP Regular Contributor
Thursday

Updates to DEFAULT (either direct or via a version post) always archive the previous record, regardless of editing method. This is 100% by design. If you don't need the old data, fire up Prune Branch History and watch as your data springs to life. Since you're using Python, try adding checks to see which records actually need updates and consolidate updates to just once per row where possible, this will reduce unnecessary archiving and speed up your processes in general (assuming your process is I/O limited, which it almost always is).

AmyRoust
by
Frequent Contributor
Friday

If this isn't the answer, I will be shocked! David, I cannot thank you enough. I'll run this late tonight when I can get an exclusive lock and then plan to get your mailing address and shower you with gifts. 

0 Kudos
AlfredBaldenweck
by MVP Regular Contributor
MVP Regular Contributor
Friday

Yeah, we've heard horror stories of tables with only a few thousand active records ending up with millions of hidden records because of Branch Versioning. It's one of the reasons we were so excited for that tool to come out. I can't find the original Idea for it, but I think if you can track it down you'd be able to relate to the posters in that thread.

0 Kudos
AmyRoust
by
Frequent Contributor
Friday

It's me! Hi! I'm the horror story! (Hmm, sounds like a Taylor Swift song..)

0 Kudos