nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

AmyRoust

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?

Find more posts tagged with

Editing

Python

Services

Accepted answers

DavidSolari

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).

All comments

AmyRoust

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

AlfredBaldenweck

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.

AmyRoust

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.

DavidSolari

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.

DavidSolari

MikeVolz

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

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.