V.10.2.1, I'm attempting to edit feature classes, but cannot due to a schema lock. I have published a map viewed via ArcGIS online for our field crews' use, and believe this is the source of the lock even though I stopped the service and changed the 'schemaLockingEnabled' property to 'false'. When I connect to the default database and select administer geodatabase to view the current locks, the user id is ArcGIS, and the lock is always started at 12:02 AM. I've even attempted to disconnect the user, but to no avail.
Any insight would be appreciated.
A published hosted layer / map service shouldn't create any exclusive locks that would prohibit you from editing the underlying feature class. Therefore there is a chance the restrictive lock is coming from somewhere else. Would you be able to post a screenshot of the geodatabase admin / locks tab using the geodatabase administrative user so we can see all connections / locks?
Also what version and type DBMS is the data stored in? Thanks!
Thanks for the info, I felt the map service shouldn't be causing a lock as well, but really didn't know where else to look. In the past, I've always tried to do my editing when I knew other users were not connected to the db. We've also created a child version of the default db for other users within the company to connect to (rather than a direct connection to the default db),but I believe that creates a schema lock when others are have our data in their mxd as well.
In the 'Lock Owner' info, FPB is an acronym for my company.
Although I have some admin rights, our db is ultimately managed by our IT Dept. I've assisted with db setup/management, but on a very limited basis. We use SQL 2012.
Thanks again, and if there's any other info you need, let me know and I will do my best to get it!
Hi Shane, thanks for the additional information and screenshot. One thing I should have asked earlier- when you say you are attempting to edit feature classes- do you mean edit in the normal sense (editor toolbar, adding deleting or modifying features/attributes of features) or are you attempting to make schema changes to the feature classes themselves (add fields, edit fields, delete fields, for example)? So far I still don't see anything that would prohibit feature edits- but what you are encountering would be expected (inability to obtain an exclusive schema lock when there are shared schema locks active) if making schema changes to feature classes. Thanks!
Hi Rex, sorry for not clarifying earlier;
I am attempting to add fields to an existing feature class in this particular instance, and anticipate creating a few new feature classes in the near future as well.
Hi Shane- Thanks for clarifying that certainly makes sense. Although you shouldn't have any issues creating new feature classes, the locking issue you are encountering when trying to add fields / make schema changes to existing feature classes would be expected (if) there are any shared locks existing at the time of the attempted change. More on this is explained here: Schema locking—ArcGIS Help | ArcGIS Desktop
"Any number of shared locks can be established on a single feature class or table at any given time. When you use ArcGIS to modify your geodatabase schema—for example, to add a field or alter rules—ArcGIS attempts to establish an exclusive lock on the data being altered. However, if a shared lock exists on that dataset, an exclusive lock cannot be established"
..."If a user wants to make changes to a geodatabase schema, the specific datasets with which he or she is working must not be in use by others. In other words, to make changes to a dataset, a shared lock must not exist on that dataset"
What it sounds like is happening is ARCGIS is likely the ArcGIS Server / publisher user that is used for hosting published map or feature services from these feature classes. I'm guessing that there is some sort of nightly maintenance that probably restarts the services around midnight each night so that what creates the initially shared locks. If you stop all services from your ArcGIS Server admin connection do the locks drop off (they should if services are halted).
I'd recommend either stopping all published services (as well as ensure that no other users are connected in Desktop) and then check the locks / attempt a schema change. We just need to ensure there are no shared locks existing on the feature class before attempting to add a field. Disabling schema locking on the services should also work but perhaps there are multiple services referencing this feature class and some haven't been set to not allow schema locking? Hopefully this is helpful- schema changes can be tricky for highly utilized data- it's all about ensuring there are zero locks on the data (which can be challenging at times).
I have determined that the published map service was the cause of the schema lock. The reason I wasn't able to clear the lock earlier when stopping the service was because I had an older, unused map service that also needed to be stopped. After stopping BOTH map services, the locks cleared. Gotta love human error!
Anyway, thanks so much for your help on this issue Rex
That's great to hear- I'm glad you were able to track down the source of that remaining lock. Have a great weekend!