My company's Portal and Collector/Field Maps implementation is finally gaining steam. As we add new feature classes or revise fields within existing feature classes in SDE, I have to turn off the map services to implement. Is there anyway to either not have to turn off these services or have it done so fast that I don't have to do database maintenance after 6 PM? The particulars of our setup:
Am I correct that if I'm just adding a field to an existing feature class, I only have to turn off the services directly impacted?
When I add a new feature class, I have to turn off EVERYTHING, which is inconvenient. What work-arounds have others implemented to deal with this? I'm assuming python scripts to speed up the process is recommended.
Thanks - Matt
Though slightly more dangerous, you can just disable the "lock schema" settings in those services.
Yes, adding a field only requires stopping the relevant services.
Adding a new FC only requires stopping the services that the FC needs to be added to, not necessarily everything.
Hi Matt, if you are using SDE as your service datasource, there is a service configuration called database schema lock, supposedly to allow schema updates to an FC. Though in my teams experience, sometimes the service still creates locks on the FC even when this is disabled. We still end up stopping the target service and then do our schema updates like add fields or apply new domains. We have a dev, test and prod environment so you can imagine the effort for just updating a single FC schema. What we do to lessen the stress is:
Thanks everyone for the responses so far. It looks like my best options are to either find the best way to bulk update the schema and turn off the services at the source (on the actual server by using the ArcGIS Server service) to speed things up. I will also try to turn off the schema lock options in the services - not sure why I haven't tried that yet.
We have versioned data within feature datasets. Contrary to Josh stated above, I am unable to create a few feature class in that feature dataset because it conflicts with an existing lock. The only way to do ANY edits to the schema, including new feature classes, is to turn off ALL services hitting anything in that feature dataset.
Should I assume based on the response that others are not using feature datasets as often as people used to?
We still use feature datasets for our utility assets and road network as we leverage flow and location analytics from its data model. We don't use them to just simply group feature classes together. And like you said, all fcs gets locked since version's is applied to the dataset level.