Upgrade Enterprise Geodatabase from 10.8.1

[ZachBodenner]

Hello, I have some questions about upgrading our egdb. Background:

Currently, egdb is on 10.8.1 on a SQL Server 2019, Enterprise deployment (server/portal clients) are on 11.1. All desktop users are using Pro 3.2, with a few exceptions that have been tough to completely pull away from ArcMap. From what I understand, it isn't inherently bad to have different egdb and client versions, though it is recommended to keep them in step. I was reading about upgrading egdb and came across this article: Upgrade Enterprise Geodatabase in SQL Server In particular, this passage caught my eye:

"When you upgrade a geodatabase in SQL Server to 11.0 or a later release, the fully qualified names of tables and feature classes will no longer contain the database name. For example, a feature class named productdata.dataowner.inventory in a 10.9.x geodatabase will be named dataowner.inventory after you upgrade the geodatabase."

This seems very important, but I'm wondering what the knock-on consequences of this change are. For example, if I have web services that contain a feature class joined to a table, will the removal of the database name affect the join? Any other concerns that I should be aware of but can't see? Finally, any other issues you may have run into upgrading your egdb? This will be my first time going through the process.

[MarceloMarques]

@ChristopherBowering -
You mentioned that you have recently upgraded several EGDBs from 10.8.1 directly to 11.1 and that was when you started to experience issues with the ArcGIS Server 11.1 services.

This might be relevant to your problem, please read.

What's new in ArcGIS Pro 3.0—ArcGIS Pro | Documentation

Restoring SQL Server databases with a new name (esri.com)

You might want to mention this in your esri support ticket #03601725.

[ChristopherBowering]

I actually came across this information earlier today and discussed the change in naming conventions internally.  Logically, we figured that if the change in nomenclature were the root of the problem, all services would be affected equally since all feature class and table names changed the same way within the EGDBs once upgraded.  However, this is not the case as some services continue to function without issue.  Through our testing thus far, the 'common denominator' continues to be the user/database connections.  We can take the same dataset, publish it out via 3 different database connections and get 3 different results; from the service working fine to it not working at all.  The varying degrees of function seem to be dependent on the database connection used during publishing.

We are planning on rebooting our other 2 servers to see if this helps.  So far we have just rebooted the server which contains the GIS Enterprise (server, portal, data stores).  SQL itself resides on a different server.

[RuchiraWelikala2]

Curious about this, when you were sitting on the 10.x version of ArcSDE, your table names were something similar to "dbname.schemaname.layername" correct? Then when you went to 11.x, they all got changed to "schemaname.layername". When you opened your ArcGIS Pro documents which had references to the old database, were all the layer sources broken? We have hundreds of layers in our eGDB published to ArcGIS Server, and cannot fathom going through and republishing everything when we do the switch. 

[MarceloMarques]

@RuchiraWelikala2 - read the article below for more information
Restoring SQL Server databases with a new name (esri.com)

What's new in ArcGIS Pro 3.0—ArcGIS Pro | Documentation

If you are experiencing any issue with ArcGIS Pro map documents or with published ArcGIS Server Services after the SQL Server Geodatabase ArcSDE repository upgrade then please open a ticket with Esri Technical Support to investigate the problem further.

[RuchiraWelikala2]

Thanks, Marcelo. We have not upgraded yet but plan to in the near future. We're on SQL Server 2017 running SDE version 10.9.1 with Enterprise 11.3 (Server, Portal, Datastore, etc.). I was just concerned the process of upgrading was going to break everything. But by the sounds of it, it looks like the database links should not be broken. Hope that applies for Attribute rules as well. 

[SuzanneKenney]

@RuchiraWelikala2 We are about to do the same thing.  Enterprise Portal is at 11.3, all desktop users are at ArcGIS Pro is at 3.3.5 (the exception to this is a few egdb users still editting annotation).  Our Enterprise SDE Geodatabase is currently at Version 10.8.1.  We are planning to upgrade our egdb to ArcGIS Pro Version 3.3.5.  How did your upgrade go?

We are also concerned with breaking connections to all of our services and connections in our projects.

.

[RuchiraWelikala2]

Hi Suzanne, we held off upgrading our database from 10.9.1 to 11.3. I would suggest you upgrade yours to 10.9.1 so it's as close to 11 as possible. My team has yet to test the upgrade procedure so nothing to report back unfortunately. I'm hoping it won't break everything or there is a batch process to rectify broken layers map services. 

[ahagopian_coj]

Hello!  Can you do the upgrade to 11.x but leave SDE at version 10.6.1 (our current version)?  

[MarceloMarques]

@ahagopian_coj - The recommendation is to have all ArcGIS Software ( ArcGIS Pro, ArcGIS Enterprise: Portal, ArcGIS Server) and the ArcSDE Geodatabase Repository at the same version. 

Client and geoClient and geodatabase compatibility—ArcGIS Server | Documentation for ArcGIS Enterprise database compatibility—ArcGIS Pro | Documentation

[ChristopherBowering]

We have resolved the issue I had been discussing with you.  There were a couple database role membership settings within SQL (for a few particular database users/connections within a specific enterprise geodatabase) which were unchecked.  Prior to the 11.1 upgrade (while still at 10.8.1 for the geodatabases), we experienced no issues despite these settings not being checked on; apparently, they now must be checked on for proper publishing from the affected users/connections.