Select to view content in your preferred language

Upgrade Enterprise Geodatabase from 10.8.1

12092
36
Jump to solution
02-16-2024 02:20 PM
ZachBodenner
MVP Regular Contributor

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.

Happy mapping,
- Zach
0 Kudos
36 Replies
MarceloMarques
Esri Regular Contributor

@ChristopherBowering - glad to know that you have resolved the problem.  : )

| Marcelo Marques | Esri Principal Product Engineer | Cloud & Database Administrator | OCP - Oracle Database Certified Professional | "About: In 1992, I embarked on my journey with Esri Technology, and since 1997, I have been working with ArcSDE Geodatabases, right from its initial release. Over the past 33 years, my passion for Spatial Databases and GIS data has become a central part of my career.." | “ The mountains are calling and I must go.” – John Muir |
0 Kudos
AndrewHayden1
Regular Contributor

@ChristopherBowering Curious, might the specific enterprise geodatabase name have been 'SDE?'  We've had a similar issue/resolution that's not impacting other enterprise geodatabases either prior or post upgrade.  Just impacting our 'SDE' database....which may have been a default database name once upon a time?

ChristopherBowering
Frequent Contributor

@AndrewHayden1 I do not believe the database was ever named just 'SDE'.  We have multiple databases within our Enterprise configuration and they've always been named accordingly to properly differentiate.  We are planning to go from 11.1 to 11.2 in a few weeks so hopefully this doesn't happen again!

0 Kudos
bcunningham04
Emerging Contributor

@ChristopherBowering 

Question... did your database contain a schema named SDE that owned all of the sde objects, or was everything owned by dbo?

Also, what were the permissions changes that you  made?

I ask this because I have one database that predates my time here and the enterprise geodatabase was enabled with the SDE schema, and I have one database that I created here and the enterprise geodatabase was enabled with DBO schema. The database with SDE schema is experiencing the same issues that you were seeing after the upgrade, but my DBO schema database is functioning just fine after the upgrade.

Thanks,

Brian

0 Kudos
ChristopherBowering
Frequent Contributor

I am fairly certain the database schema is SDE.  However, we updated multiple geodatabases - all with the same schema - and encountered varying degrees of functionality loss...from complete to none.

Within SQL Server Management Studio, I went into the database, went to the Users folder under Security then right-clicked the Properties of the data connection/user which was problematic.  Under Membership, 'db_datareader' and 'db_datawriter' needed to be checked on.  This particular user has full editing privileges so it could be different for you depending on your user types.  Oddly, everything worked fine (with these boxes being unchecked) in 10.8.1.  Even stranger, we have other identical users where this 'fix' did not ultimately work.  This was honestly a shot in the dark that happened to work; I don't have a deeper explanation unfortunately.  ESRI had no idea what was going on so I got lucky I suppose.

 

0 Kudos
ZachBodenner
MVP Regular Contributor

If this helps anyone, I went ahead and did this upgrade with absolutely no testing (not super great, but here we are), and it was essentially easy breezy. The only thing that wound up needing attention was that any place we had a referenced web service where a feature was joined to a table, those needed to be re-joined and republished because the database name no longer appeared in the name of the joined tables, but did still appear in the previously joined attribute names. So if we had Feature joined to Table on Field, it looked like:

databasename.schemaname.Feature.Field joined to databasename.schemaname.Table.Field

 

We just had to clear out the databasename by redoing the join. Small thing!

Happy mapping,
- Zach
0 Kudos
enipla9
New Contributor

Oh man. Will .sd connection files still work? This is jacking up a lot of stuff for sure.

0 Kudos