Is there a way to edit a geodatabase schema without having to stop services?

[JoshWhite]

Is there a way to edit a geodatabase schema without having to stop services?

This has become a huge headache for me. Everytime I have to make a small schema change or add a new feature to a feature dataset, I have to stop all services related to the dataset make the change, ensure it is registered as versioned again and then restart the services.  It takes three or four times longer than it should.

Also, there needs to be an easy way to check to see if a dataset is versioned with a symbol or something.  It takes forever to check every single dataset to make sure it is versioned before I restart services.

[JakeSkinner]

Hi Josh,

I recommend to users that they replicate their read-only data to a File Geodatabase, and then create the service from the file geodatabase feature class.  The performance is usually faster, and it will act as another level of security since you no longer have a service accessing your enterprise geodatabase.  Also, you will will be able to add fields to the SDE feature class and then synchronize the new field to the file geodatabase feature class without having to stop your service following steps in this article.

Also, you could create a python add-in or a script and use the Describe function to iterate through your feature classes and report which are (or are not) registered as versioned.

[JoshWhite]

Sounds like a good workaround but wow is that a lot of extra steps to do. 

[AsrujitSengupta]

What kind of services are you using? Services can be set in such a way that they don't create any Schema lock on the data by themselves.

ArcGIS Help (10.2, 10.2.1, and 10.2.2)‌

python - How to prevent ArcGIS SOC from locking Oracle tables? - Geographic Information Systems Stac...‌

Map services, SDE and locks | Esri Australia Technical Blog‌

What Jake suggested in the previous post (Replication) will work fine, if you are just modifying the schema of existing data.

However if you are adding new Feature Classes to existing datasets, the replication process won't be a suitable option (unless you are ready to recreate the replica every time)

[JoshWhite]

I have map services and locator services

[JoshWhite]

and feature services

[AsrujitSengupta]

Map Services and Feature Services will allow disabling schema locking.

Geoprocessing and locator services don't support that (I am not completely sure about the locator services though).

You may give that a try and see if that helps.

[GaryMacDougall · Accepted solution]

Josh

Map services have a schema locking property in advanced. You can
set this to false., but there are some things users need to understand when
they do this. See the following doc…

http://resources.arcgis.com/en/help/main/10.1/index.html#//0154000005z9000000

thanks

Gary

[JoshWhite]

Gary,

I will try to only disable my one main base service that locks almost all of the feature datasets.  It is the main layer that probably receives the least edits but is needed in virtually every webmap (parcels, addresses, etc).  I will leave my utility layers alone so as to avoid problems, thanks for your help.

[JoshWhite]

Is there really ever any cause to worry about just disabling the schema locking on all services.  Anytime a feature class is removed, the service should be restarted anyways so I don't see what the issue is.

Esri help:

"When schema locking is disabled, it is recommended that you only update your source dataset schemas when the service is idle. If you update the dataset schema when the service is under load, users of your map service may experience unexpected behavior such as layers and fields missing, queries failing, and service unavailability. Changes to the schema of the dataset need to be carefully planned; permanently removing datasets may leave your map services in an inconsistent state."

I don't ever have a large load and can usually recover quickly with a quick refresh of a service.  I do know approximately when my peak usage is so I can avoid that.  Best time for me will be at the end of the day.