Manual Release of ArcGIS Schema Locks

01-07-2020 02:14 PM
Status: Open
Labels (1)
Occasional Contributor

This particular issue has been driving me crazy in ArcMap, ArcCatalog, and ArcPro and I was only able to find it listed alongside other concerns or related to enterprise geodatabases. Therefore, I created this post to highlight this specific issue and its presence across the platform.

Here are a couple of example scenarios:

I just made a copy of a file geodatabase feature class to a USB drive to transfer to another computer (that other computer does not have internet access). The new feature was added to the ArcPro project, creating a schema lock. I removed the new feature from the ArcPro project, but the schema lock to the USB drive remained. I was forced to shut-down ArcPro in order to get it to release the lock so I could "safely" remove the USB drive from the computer. There should be a way for me to get ArcPro to let go of the lock without closing the program.

I had two legacy ArcMap documents open that point to the same shapefile. I noticed a spelling error in an attribute that was initially included in both ArcMap documents, but was really only needed in one. I removed the data layer from the one where it was not needed, but ArcMap did not release this schema lock. I had to shut-down both ArcMap documents to get the schema lock released so I could fix the spelling error in the attribute table.

I noticed others have documented their frustration with similar problems in the Manage Schema Locks and Improve Arc Catalog Functionality forums, but I wanted to create this page to highlight the lack of a refresh option in the schema locks. I appreciate that SDE administrators now have the ability to remove schema locks, but what I'm asking for here is to be able to "refresh" the schema locks without shutting-down the program.


ArcGIS Pro's schema locking is far more aggressive than even ArcMap. If you even touch an SDE connection with Pro - it schema locks everything and you cannot release it until you reboot Pro. We regularly work with different user connections in SDE to restrict access to the database and this is incredibly painful. Having good security practices, like limiting user access through user connection files should not be this troublesome.

What's the risk in not having schema locking? If I'm being honest - I'd almost rather not have to deal with schema locking at all. It causes so many headaches and so much lost time in:

 - rebooting arcgis

 - searching for services that may be locking

 - Trying to find users that may be locking

I imagine the worst that could happen is a user editing a database while a user deletes a field is the worst case scenario. At which point they might receive an error about a column not existing and the edit can't be applied. This is a scenario any dba should be aware of anyways and not be making changes while users are editing databases.


Agreed that this is ridiculous. Please, can we at LEAST have a means to review which schema locks a Pro project has in place and release them? It even puts a schema lock on the last locked schema even if the map which used that schema is closed, such that a Pro project with no open maps or connections is still placing schema locks.



Yes, I have found myself in a bit of a puzzle with schema locks for a feature service I have published to Portal. However, I have turned off all services through ArcGIS Server Manager.

I triple checked that no other person is using the feature class in a project/map through shared sde instances. And we all restarted our PCs to be very certain no lock from our computers could be active. And it was still saying I had a lock. When our admin did a deeper dive, it said that I was the only one to have the lock, and this was when my device was turned off and all published services were still off. 

Pro now has a "domain usage" search tool that has been very helpful with this type of troubleshooting. Is there a way to have a "feature class/feature service" usage tool as well? Something to make it easier to find the issues with these locks.