I am using ArcGIS Pro v3.0

I have written a script to perform a set of toolbox operations on a couple of layers in my map.

One thing I noticed was that more often than not I forget to save my edits before running the script and I get some errors as some of the operations cannot be performed whilst the layers are being edited.

What I have tried to do is therefore to find the command that emulates the following GUI "Save" button:

enter image description here

I've had a look at the ArcPy editor page, without success.

Here is the code I have written to try and save any unsaved edits and stop editing:

# I access the editor
edit = arcpy.da.Editor(arcpy.env.workspace)
# I check if the editor is currently active
if edit.isEditing == True
   # If it is I close the editing session and save any outstanding changes

But when I check for edit.isEditing it always returns False even when I clearly have some unsaved edits.

The workspace I use to instantiate the editor is the database where the layer files are stored. I tried specifying the individual features but that doesn't seem to work.

Ultimately the state I'm trying to get to is the one I get once I clicked the "Save" button above, followed by the "OK" on the pop-up below which results in all edits being saved and the "Save" button being greyed out.

enter image description here

  • 1
    You need to understand the difference between a feature class and a layer in order to make progress with ArcPy (layer files are not stored in a database). You haven't provided any code, so it's difficult to help. Please Edit the Question.
    – Vince
    Jul 6 at 13:19
  • @Vince I have added the code I tried using. As you can see it is pretty simple but it seems not to work. In a sense I am not surprised the Editor call seems to create an instance of the Editor class. But I haven't found a way of accessing any existing instances that could then be checked and closed.
    – Sorade
    Jul 6 at 13:26
  • 1
    Have you tried using the IsBeingEdited method? You're creating a new Editor and this method does not require it.
    – evv_gis
    Jul 6 at 13:39
  • Thanks @evv_gis, that sounds like exactly what I need... even if I couldn't terminate the edit session, I could still prevent the script from running and give the user a warning. Unfortunately it isn't available in ArcGIS 3.0, only in 3.1
    – Sorade
    Jul 6 at 13:46

1 Answer 1



Add edit.startEditing(False, False) after declaring your editor.

More details

From this doc on arcpy.da.Editor:

editor = arcpy.da.Editor(workspace)
editor.startEditing(with_undo=False, multiuser_mode=True)

# Do things here.


It would appear that you are missing startEditing() and possibly startOperation() (see below).

Things to look out for

I have found the following caveats using 10.8:

  • The documentation on with_undo and multiuser_mode doesn't make sense to me regardless how many times I read it. What has worked is building a little harness around it and testing all the possibilities (luckily there aren't many) until I find the one that works.

  • The startOperation() and stopOperation() calls raise exceptions for me more often than they make a valid and positive difference. My current standard practice is to ignore them when initially writing the code, then add them later if necessary.

  • The context operations do not seem to work. You may be tempted to use with arcpy.da.Editor() but this always causes strange errors with misleading messages for me.

  • In many situations where I thought I would need an edit session and even many when I was told by others (who know) that I would definitely need an edit session, I did not need an edit session. You may try your edits without and see if they work. Certainly versioning plays a critical role in this but it looks like you may be using an FGDB, which would put you clearly in the maybe sometimes realm.

  • This pattern works best for me:

        editor = arcpy.da.Editor(workspace)
        editor.startEditing(with_undo=False, multiuser_mode=False)
        # Do things here.

    There is some discussion about using your method of checking for a condition, versus this one of just trying the operation and letting it run if it works. Python convention seems to prefer the latter over the former. The latter certainly seems to be easier in this context.

I hope that something in there solves your problem.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.