Select to view content in your preferred language

Are changes to ArcPy scripts needed when accessing SQL feature classes after upgrading the enterprise geodatabase to Pro

180
3
a week ago
RandyKreuziger1
Frequent Contributor

I've only upgraded a test SQL geodatabase from 10.9.2 to 3.5.  When the feature classes are listed, the geodatabase name is no longer there.  For example, geo.dbo.county now shows up as dbo.county.  Does this mean all python scripts referencing feature classes in an enterprise geodatabase need to drop the database name to keep working?

Do Map Services have to be republished?

Thanks

 

0 Kudos
3 Replies
DavidSolari
MVP Regular Contributor

Absolutely read through Tony's link, but the short answer: probably not. My teams been slowly stripping the DB name out of our hardcoded paths as a sanitary thing but we haven't seen issues with cursors, describe constructors and so on since going from 10.9 to 11.1. Direct database access might be more picky, but SQL Server seems to handle a redundant DB name just fine so maybe not. Just leave some time to smoke test your most critical tasks during the upgrade period and you should be good!

HaydenWelch
MVP Regular Contributor

I've found it to be really important to almost never hardcode anything. If you need specific values, use a config file or environment variables or a context object.

It's really easy to have a lot of things break in weird ways when you assume nothing will ever change (I've even had to deal with people recreating fields as a string instead of an int which later caused sorting issues because string numbers over 9 don't sort like integers over 9 lol).

Luckily we live in an era with modern text editors that come packaged with ripgrep so ctrl+f replacing all the places you hard coded a name is pretty simple.

0 Kudos