ArcGIS Pro 2.6.x Issues with ArcPy: Needing help with stale connections and state locks on SDE connections

Question

Hello everyone, I feel like I've been plagued with unusual Python 3.x (arcpy) issues ever since I upgraded to 2.6.x The latest issues I'm facing include stale SDE connections and state locks not properly releasing upon completion when I am disabling/enabling Editor Tracking (arcpy.EnableEditorTracking_management and arcpy.DisableEditorTracking_management). My workflow includes disabling editor tracking, calculating some values with an update cursor, then re-enabling editor tracking on an SDE database. After discovering some locking issues not going away, I've isolated the issue specifically to the enabling/disabling of editor tracking. I've created a testing environment (and script) for studying these tools specifically which will be provided below. Usually, arcpy.ClearWorkspaceCache_management does the trick and cleans up the script's locks, but that isn't working with the above tools for whatever reason in Pro 2.6 update of Python. To provide more clarity, I run many workflow tools in sequence so my goal is to clean up all locks affiliated with each tool before beginning the next. I have confirmed that the state locks are properly releasing in the Python 2.7 flavor of arcpy, and I never had issues with Pro 2.2-2.5 with these issues either. Here is my script that I've been testing with: import arcpy from Static_Values import Class_Static_Values as stat_val import time arcpy.env.workspace = stat_val.sdeConnection_RegionalGIS_DefaultVersion fc_list = arcpy.ListFeatureClasses() for fc in fc_list: if "EMS" in fc: #arcpy.DisableEditorTracking_management(fc, # "DISABLE_CREATOR", # "DISABLE_CREATION_DATE", # "DISABLE_LAST_EDITOR", # "DISABLE_LAST_EDIT_DATE") arcpy.EnableEditorTracking_management(fc, "CreateID", "DateCreate", "UpdateID", "DateUpdate", "NO_ADD_FIELDS", "UTC") print(arcpy.GetMessages()) print("attempting to remove locks...") arcpy.ClearWorkspaceCache_management() print("attempt complete...") # The following loop allows me to review/refresh the Geodatabase Administration window for 10 seconds to verify if any locks still exist from the above line of code. counter = 0 while counter < 10: time.sleep(1) counter = counter + 1‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Has anyone else encountered this, or can you think of other options to try in order to clean up the locks? Once the above, isolated script gets to Line 33, two stale SDE connections and two persistent state locks remain and do not go away until the script completes its full execution after Line 41. The two stale connections are highlighted here (ignore the grayed out one, as that is my current view within Catalog for studying purposes): The two persistent state locks are highlighted here (ignore the grayed out one, as that is my current view within Catalog for studying purposes): Interestingly enough, I can get one of these state locks to disappear if I include the line arcpy.env.workspace = None just before the arcpy.ClearWorkspaceCache_management() line, but I don't recall ever needing to do that. I also can't figure out what else is leaving the other state lock. I've tried resetting the environment, clearing the cache, garbage collection, as well as deleting the fc_list variable with no luck. Any help or insight would be most appreciated!

David_Lindsey · Answer

Hey Mehdi,

I wanted to follow up with some findings. I was playing around with your suggestion, and it partially works by removing some stagnant locks. However, I do not believe it can solve all of my issues at the moment.

I get the following error.....
RuntimeError: Unable to disconnect: The connection ID provided is for the current administrator connection.

...which led me down a rabbit hole:

This error is occurring when I attempt to iterate each user and remove select ones matching "DBO" (which is what the script currently utilizes). Since the script itself is executing the function, it doesn't appear that I am able to disconnect the script while it's still connected.

And since the script isn't properly disconnecting itself after running certain tools, I guess that puts me in a Catch-22 situation. Ha.

The Esri documentation:
DisconnectUser—ArcGIS Pro | Documentation

Anyway, Esri Support let me know today that the locking issue can be replicated on the Esri side and is suspected to be a defect specific to Pro 2.6.x. I should be hearing more from Esri Support this week concerning this issue, so I'll follow up with more once I hear back.

David_Lindsey · Answer

Thanks, Dan. Issue now logged with Esri Support. I'll report back with any new findings!

David_Lindsey · Answer

Hi Mehdi,

I appreciate the feedback. I am aware that this could help remove locks, but I am hesitant to incorporate it into our scripts. We use database replication and provide various web services that act as users connected to our SDEs. The user name information that Esri tracks within the user list is not granular enough for me to determine which "DBO" user lock is directly tied to the script itself, unless I add more fancy coding to keep track of lock times perhaps (no thanks!).

An idea we may consider is creating a script-specific username with DBO privileges so that I can more easily identify any locks created by the script itself. Even this seems like a band-aid fix though. I'll reach out to Esri Support today and report back any new findings. Thanks again!