I have a script for a geoprocessing tool that grabs values from a point feature class, and populates them into related tables for that feature class. It also calculates another attribute field in those related tables. I've run into quite an odd bug concerning the arcpy.da.Editor process, and I'm wondering why it's happening or if there is a work around.
I've set up the start editing, stop editing process as it's laid out in the ESRI help file. I'm editing related tables in a versioned enterprise geodatabase.
The first time I run the tool, it stops on the 'edit.startEditing' line and returns an error with no exception. If I simply click Close, and the tool window comes back up, and immediately run it again without doing anything, it makes it all the way to the 'edit.stopEditing(True)' line. Here it throws a RunTime: Start Edit Session error. It will continue to fail here, unless I do the following:
I click close, and the tool comes back up. With the tool still open (and parameters all still filled in and unchanged), I start an edit session on the points, manually, and then immediately stop editing. This prompts me to save my edits. Why? Because the tool did actually make the edits, it just failed on the stop editing line (which means an edit session did in fact start). If I click No on saving the edits, and then proceed to run the tool again, nothing changed, parameters all filled in, it runs successfully. And it will continue to run successfully without these extra steps every time I run the tool, until I exit ArcMap. After I exit, if I open ArcMap again, I have to go through those steps I mentioned to get it to run successfully.
Why is it, one, failing on the initial 'start editing', then in the very next try fails on the 'stop editing' claiming there is no edit session started when there obviously is one. And two, why does it require me to manually go through those steps i described to have it run successfully, and get past the 'stop editing' line? The fact that it runs flawlessly, and through continuous tries, after those manual steps are done shows I have things set up right. Something is tripping it up, and not letting it start editing initially, and then not saving edits either.
Note: I've tried variations on the start editing inputs. I've tried starting and stopping an edit session before I ran the tool. I've tried different ways to connect to the sde database (my 'sdeconnection' variable), and I've tried different placements of the start and stop operations. I have yet to find success. I've been stuck on this for weeks and I can't find a similar problem on here, which is leading me to think it's a bug. But I hope I'm wrong. It's driving me up the wall.
Example of the section of code (with some variable names changed):
edit = arcpy.da.Editor(sdeconnection) # using update cursor, update the plot number field in the related tables. edit.startEditing(False, True) # starts edit operation # This cursor will take the dictionary of the GlobalIDs and plot numbers, find the related records, # and transfer the appropriate Plot Number from the dictionary with arcpy.da.UpdateCursor(relatedtable, ["ID", "Plot"]) as cursor: edit.startOperation() for row in cursor: gid = row for key, value in plotdict.iteritems(): if gid == key: row = value cursor.updateRow(row) edit.stopOperation() edit.stopEditing(True)
If you use the syntax highlighter it's easier to read and trouble shoot code. (see cartoon below...) I don't see:
Editing in a versioned environment via python can be tricky at times; If it starts an edit session but errors out, that session will still be open and you'll get the error telling you so.
The edit.startOperation() is within the with statement, right before the for loop for the update cursor.
But I've also tried outside of it, right before the with statement. Both ways, same problem I'm having.
That's why I like the syntax highlighter.... I always follow the model in example 2 from the help :
edit = arcpy.da.Editor(workspace) edit.startEditing(False, True) edit.startOperation() #do your edits here edit.stopOperation() edit.stopEditing(True)
How are you running this? You may want to try it first line by line in a python window in ArcMap or ArcGIS Pro to work out the wrinkles before trying to execute it as a stand alone script. That way you can have control over when the edit session is truly started/stopped....
I've done it that way, and set it up exactly like example 2. It still throws the same error, telling me I don't have an edit session started.
I've also added lines in for if editing is True, right before the edit.stopEditing line, and to display a message. The window will display the message that editing is True (an edit session is started), and literally the next line in the code is the edit.stopEditing and it will throw the error saying no edit session is started. This is why it's confusing me, it contradicts itself.
It makes it through the start and stop operations, and completes the with statement and for loops. In fact, the edits are made (that's why if I manually start an edit session after the error, using the Editor toolbar, there are edits to save, and they are visible in the attribute table if I open it). It fails on the edit.stopEditing.
Just confirming, you tried placing the startOperation before the UpdateCursor?
edit = arcpy.da.Editor(sdeconnection) edit.startEditing(False, True) edit.startOperation() with arcpy.da.UpdateCursor(relatedtable, ["ID", "Plot"]) as cursor: for row in cursor: gid = row for key, value in plotdict.iteritems(): if gid == key: row = value cursor.updateRow(row) edit.stopOperation() edit.stopEditing(True)
Yes, I have put the edit.startOperation() before the update cursor. Still getting the error.
The only fix I have found is manually starting an edit session from the toolbar after letting the tool hit the error. Once I manually start and stop the edit session, then re-run the tool, it runs great. And I can run it repeatedly after that. So that suggests that I have it set up right.
But if I close arcmap and open a new session, I have to do the manual start/stop after the error to get it to work again.
I'm starting to think it has to do with connecting to an enterprise SDE, as this script works flawlessly on a file gdb with no errors.