How? Editing Domains for Already Published Feature Services that Reference Registered Data Store (SDE) on SQL

[DS_GIS]

We are running Enterprise 10.8.1, SQL Server, running all our work in ArcPro 2.7, and have an SDE  in place that is backing Field Efforts using ArcGIS Collector. In order to increase efficiency in the field we have created multiple coded domains for different fields. It was our goal to ensure that these wouldn't need to be changed in the future as a domain or field being altered is considered a schema change and means the feature service needs to be overwritten or re-published.

Unfortunately, we now need to alter a few of the domains. And, at this point we have over 100 services running from this SDE. I have tried testing to see if we can change the domains without overwriting or re-publishing. Below are the steps I have tested. 

1. Stopping all services that are using a certain domain > Altering the domain > Restarting the services = The result of this is that the changes don't come through and it registers the old domain

2.  Stopping all services that are using a certain domain > creating an entirely new domain > swapping the old domain out for the new in desktop > restarting the service = the result of this is that no domain appears at all. If we stop the service again, and then swap it back to the old domain it will pull the old domain through. 

The other limitation is that we can't edit many of these domains as the feature services will cause schema locks. 

My current thinking is we need to create entirely new domains > assign them to the services 1-by-one > and overwrite them so we don't need to re-add them to all the maps. 

Before we go forward with this I wanted to kindly inquire of this community if anyone else had worked with domains that are published to 'live' data from an SDE? If so, would they happen to have any other suggestions of things I could try to make this more efficient please?

[Joshua-Young · Accepted solution]

Back in the fall I had to update domains for a branch versioned feature service. At the time we were running ArcGIS Enterprise 10.8.1, SQL Server, and ArcGIS Pro 2.5. I was not manually updating the domain values but using the Table to Domain geoprocessing tool instead. I had to restart the service and close/reopen ArcGIS Pro to see the changes. To see the domain changes without restarting anything I had to go into the service properties and uncheck the "Lock Schema" option. The only other thing that I can think of is even though you are changing the domain value in the domain list you will still need to update any features that are referencing any domain values that were changed. I know I have forgotten to do that in the past.

The second process you referred is showing no domain after switching to a new domain because the a config file for the feature service is still looking for the old domain which the feature class is no longer using. You would have overwrite the service to have the service know to use the new domain.

You should be able to update your current domain list without have to overwrite anything.

[DS_GIS]

Hello Joshua-Young, 

Thank you very much for this! So, it seems like my best bet/least amount of effort is to edit the existing domains. One of my favorite aspects of ArcPro was not needing to use the table to domain tool, and being to edit them within the domain view. However, if you say this tool has worked to edit an existing domain and get it to cascade to the feature service, that is something I'd like to test. 

I know you said you were working with only 1 feature service that was branch versioned. So, out of curiosity, do you think this workflow would be successful if say, 50+ feature services were calling the same domain that you were editing? 

Thank you for further explaining the 2nd process. That helped me connect the dots! I truly appreciate it. 

[Joshua-Young]

As long as the "Lock Schema" is turned off on all 50+ feature services, I would think you should be able to edit the domain successfully. That is assuming that there is not some ArcGIS Pro 2.7 bug preventing the changes. I think also you should be able to manually be able to edit the domain values without using the Table to Domain tool.

[DS_GIS · Accepted solution]

Hello Joshua-Young, 

I wanted to kindly follow-up on this. We were able to get the domain changes to push through using ArcPro 2.7.2 for new fields. I stopped ALL services in order for this push to go through. We observed there is actually a delay in the new domains populating. So, we would stop all services on ArcGIS Server running the domain > apply changes in ArcPro > Save > Restart Services > the New field was still not seen > the next morning the new domains were there. 

The last item we are still working to address is the deletion of a domain field. This one has proved to be difficult as we keep getting a new set of errors thrown. Thank you kindly for all your advice!

[Joshua-Young]

Glad to hear that the new domain is working. Is it the domain that will not delete or an attribute field that is using the old domain? If you are trying to delete the domain, have you tried the Domain Usage tool to see if there are any feature classes still trying to use the old domain?

[DS_GIS]

Thank you kindly for for reaching back. It's a single domain row that won't delete. We aren't trying to delete a field in the attributes. The deletion of an entire domain from the SDE is successful after it's no longer in use. But, not a single line item within a domain.

Yes, we've been applied the domain domain usage tool. It's a fantastic feature that we've found very useful. Thank you very much for sharing.

[JakeSkinner]

I've run into this issue, and I believe it's something specific with ArcGIS Pro 2.7.  I would recommend logging a case with support so they can log this. 

The workaround I found was stopping the service, updating the domain in ArcMap, and then restarting the service.  The service then picked up the new domains.

[DS_GIS]

Hello JakeSkinner, 

Thank you so very much for these insights! I had a case open with Esri recently where this was mentioned as an aside. I've also had troubles pulling in views and tables from SQL that I have connected to without issue before. Additionally, I'm getting an odd error thrown when I try and publish them that is entirely new to me. This behavior wasn't exhibited in 2.6. 

I have not tested editing in ArcMap, but I think we could try this. Thank you again!

[Joshua-Young]

You may want to try using ArcGIS Pro 2.6 to make these changes. Technically ArcGIS Pro 2.7 is at the 10.9 version when it comes to geodatabases and is expecting to connect to ArcGIS Enterprise 10.9. I just ran into an issue with trying to publish a new feature service from 2.7 to ArcGIS Enterprise 10.8.1. After several days of troubleshooting and digging through log files I found the issue was due to a new attribute rule that was created using 2.7. Apparently when 2.7 created that attribute rule it changed version level of the feature class in the SQL Server enterprise geodatabase and ArcGIS Enterprise 10.8.1 refused to connect to the feature class. Removing the attribute rule in 2.7, going back to ArcGIS Pro 2.6, recreating the attribute rule, and then publishing fixed the problem.