https://community.esri.com/t5/python-questions/are-changes-to-arcpy-scripts-needed-when-accessing/m-p/1719147#M75364 <P>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.</P><P>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).</P><P>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.</P> Fri, 07 Aug 2026 02:18:24 GMT HaydenWelch 2026-08-07T02:18:24Z https://community.esri.com/t5/python-questions/are-changes-to-arcpy-scripts-needed-when-accessing/m-p/1717918#M75357 <P>I've only upgraded a test SQL geodatabase from 10.9.2 to 3.5.&nbsp; When the feature classes are listed, the geodatabase name is no longer there.&nbsp; For example, geo.dbo.county now shows up as dbo.county.&nbsp; Does this mean all python scripts referencing feature classes in an enterprise geodatabase need to drop the database name to keep working?</P><P>Do Map Services have to be republished?</P><P>Thanks</P><P>&nbsp;</P> Fri, 31 Jul 2026 20:38:32 GMT https://community.esri.com/t5/python-questions/are-changes-to-arcpy-scripts-needed-when-accessing/m-p/1717918#M75357 RandyKreuziger1 2026-07-31T20:38:32Z https://community.esri.com/t5/python-questions/are-changes-to-arcpy-scripts-needed-when-accessing/m-p/1717925#M75358 <P>This might help.</P><P>&nbsp;</P><P><A href="https://community.esri.com/t5/arcgis-enterprise-questions/upgrade-enterprise-geodatabase-from-10-8-1/td-p/1383669" target="_blank">https://community.esri.com/t5/arcgis-enterprise-questions/upgrade-enterprise-geodatabase-from-10-8-1/td-p/1383669</A></P> Fri, 31 Jul 2026 21:51:02 GMT https://community.esri.com/t5/python-questions/are-changes-to-arcpy-scripts-needed-when-accessing/m-p/1717925#M75358 TonyAlmeida 2026-07-31T21:51:02Z https://community.esri.com/t5/python-questions/are-changes-to-arcpy-scripts-needed-when-accessing/m-p/1718739#M75360 <P>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!</P> Wed, 05 Aug 2026 17:13:57 GMT https://community.esri.com/t5/python-questions/are-changes-to-arcpy-scripts-needed-when-accessing/m-p/1718739#M75360 DavidSolari 2026-08-05T17:13:57Z https://community.esri.com/t5/python-questions/are-changes-to-arcpy-scripts-needed-when-accessing/m-p/1719147#M75364 <P>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.</P><P>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).</P><P>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.</P> Fri, 07 Aug 2026 02:18:24 GMT https://community.esri.com/t5/python-questions/are-changes-to-arcpy-scripts-needed-when-accessing/m-p/1719147#M75364 HaydenWelch 2026-08-07T02:18:24Z