arcpy.analysis.Clip stops edit session?

[Jeff-Reinhart]

Why would arcpy.analysis.Clip() affect an ArcGIS Pro edit session and is there any way to prevent that?

Steps to reproduce:

1. Edit tab | click Edit button

2. Choose Workspace window | choose Enterprise Geodatabase Data (versioned) | click OK

3. Run Python script from Toolbox with code:

import arcpy
in_features = 'Feature Layer 1'
clip_features = 'Feature Layer 2'
out_feature_class = r'D:\my_gdb.gdb\intersect_result'
arcpy.analysis.Clip(in_features, clip_features, out_feature_class)

This results in the Edit session being stopped (as evidenced by the other Edit tools becoming disabled).

At face value, this does not seem like it would be a big problem. But in a complicated application where an edit session is being managed by the Pro SDK and users need to run a process like this without it interrupting their edit sessions, it causes significant issues.

[Jeff-Reinhart]

To further isolate arcpy.analysis.Clip() as the culprit, I also tried:

import arcpy
in_features = r'D:\not_my_enterprise.gdb\feature_layer_1'
clip_features = r'D:\not_my_enterprise.gdb\feature_layer_2'
out_feature_class = r'D:\not_my_enterprise.gdb\intersect_result'
arcpy.analysis.Clip(in_features, clip_features, out_feature_class)

So no inputs/outputs from the Enterprise Geodatabase that is the Workspace for the edit session and no layers from the current Pro project.

Still results in the edit session being stopped.

[Jeff-Reinhart]

Also tried arcpy.analysis.SpatialJoin(). That stops the edit session as well. Guessing all of arcpy.analysis does this then?

[AlfredBaldenweck]

What version are you in? 

I had a related issue a year or so back that was resolved in 3.5

BUG-000174197: When manual edit sessions are enabled, running a geoprocessing tool without pending edits turns off the edit session.

That being said, I'm not sure if we tested for running a tool in a script; I only noticed it doing it manually.

So I just did a quick test just now in the Python Window and a Notebook in 3.5 and couldn't replicate.

x = r"C:\Users\...\Default.gdb\Polygon"
y = r"C:\Users\...\Default.gdb\Polygon_1"
z = r"C:\Users\...\Default.gdb\PolygonClip"
arcpy.analysis.Clip(x,y,z)

HOWEVER. The same code in a PYT and an ATBX turned off the session and turned it back on. 

I'm interested in hearing more

[AlfredBaldenweck]

Also noticed that if I used the specific-workspace edit session (I originally tested on a multi-workspace session), the python window gets a lock error if the data being clipped is in the same workspace. 

[DanPatterson]

UpdateCursor—ArcGIS Pro | Documentation

as an example, perhaps it is by omission, it states

Opening simultaneous insert or update operations on the same workspace using different cursors requires the start of an edit session.

so closing the edit session is the default for geoprocessing operations except those associated the editor toolset

An overview of the Editing toolbox—ArcGIS Pro | Documentation

[DanPatterson]

Undo geoprocessing tools—ArcGIS Pro | Documentation

There is a fairly protracted discussion about editing, starting-stopping, enabling-disabling in the above link, but short of looking at each tool to see whether edit sessions are supported or not, there doesn't appear to be a "list"

[Jeff-Reinhart]

@AlfredBaldenweck I am using version 3.5.

@DanPatterson I also tried arcpy.management.MakeFeatureLayer() and even that stops the edit session. From what you are saying, it seems that this is not a bug and is intended functionality. This functionality ruins being able to run a lot of arcpy tools from scripts mid edit session. So can we submit a "bad design" ticket instead of a "bug" ticket? 🤣

PostGIS and QGIS just keep looking more and more appealing.

[DanPatterson]

they would probably say "get organized" 🤣