ArcGIS Pro 2.2: arcpy starts an editing session on a polygon Feature Class in a File Geodatase (LOCK files created in FGDB), exports a MapSeries map to JPG with that Feature Class as the index layer, then stops editing on that Feature Class (LOCK files automatically delete from FGDB).
ArcGIS Pro 2.4.1: arcpy starts an editing session on a polygon Feature Class in a File Geodatase (LOCK files created in FGDB), exports a MapSeries map to JPG with that Feature Class as the index layer, then stops editing on that Feature Class (LOCK files REMAIN in FGDB). The arcpy script moves on to create the next polygon in order to export the next mapseries page but then ERRORS with:
Updating software is meant to fix problems like this, not introduce them... I'm assuming this is a bug?
As expected, uninstalling 2.4.1 and reinstalling 2.2 solves this issue.
I have logged a bug report with ESRI. But I'd like to hear other people's thoughts here.
We've recently discovered the same behavior with SDE GDB's as well, which prevent other users from modifying the schema:
Add a SDE feature class to a new map and click the edit ribbon but don't edit anything.
INSERT INTO @tblVariable
SELECT v.*, t.TEXT
FROM @tblVariable v
INNER JOIN sys.sysprocesses sp ON sp.spid = v.SPID
CROSS APPLY sys.dm_exec_sql_text(sp.sql_handle) AS t
where DbName = 'GRSM_VEG_MAP'
ORDER BY HostName DESC, CPUTime DESC
and note how many transactions return from the user/host name that has this feature class open in Pro
Close the map (but not Pro)
Rerun the same SQL query
Note there are still transactions (same host/user) open associated with you doing nothing more than adding the FC to a new map.
From another host/user, in Cat view, right click on that feature class in SDE, attempt to add a new field (design fields). Fails...contact ESRI for TS....
Through 2 weeks now of isolating this, as we have many feature classes we can't update because of this ghost schema locking, we narrowed it down to:
If one user adds a GDB feature class to a Pro map on their machine, then closes the map, but the project remains open, other users on other machines cannot modify that feature class, which seems similar to the behavior you are seeing with the FGDB.
What we've discovered is, if we want to make a change to a feature class, EVERYONE has to shut Pro down, as we have no idea what maps in what projects have "touched" that feature class.
Of more interest, remember, the feature class is now no longer "touched" in a map, remember, we closed the map, saving and closing Pro fires more transactions associated with this host/user (in this specific database).
Close and restart pro, transaction locks are gone....