Error 00732 from GP Service after 10.5 Upgrade

Question

Hi.  We recently upgraded our environment to version 10.5 and I am now unable to successfully execute a simple geoprocessing service.  The gp service broke after the 10.5 upgrade (for a known reason).  I fixed it and successfully published it.  However, it fails with error 000732 when run.  With this error message:

The error message is actually correct.  ...SQLSAZD02_GdbGisuPub.sde\BoundaryCountyPolgyon does not exist.  The feature class reference is missing "GdbGisuPub.GISU" in front of BoundaryCountyPolygon.

My script references "GdbGisuPub.GISU.BoundaryCountyPolygon" (or it wouldn't work).  Somehow during publishing it gets changed.

Does this look familiar to anyone?  Anyone know what I am doing wrong now?

Thanks.

ViktoriaMagnis · Answer

Hi

Did you ever find a solution to this, I am having the same issue.  The SDE file in the v101 folder is altered and instead of using a SQL Server it's an Application Server Connection.

ScottFierro2 · Answer

Ahh ok so first thing I see is in your local you are using a database connection that could be navigated to within ArcCatalog by going to the built in "Database Connections" section (inside your local copy listed as the "local variables"). Can't guarantee this is or isn't the issue but we have found some odd behaviors when using the ESRI built in DB connections.

You could consider setting up a local folder location and copying the sde connection into the local path (via Catalog)then re-sourcing your model using that connection instead. We solely use this workflow so after building a new DB connection in Catalog we copy all sde connections into D: \Arcgisserver\Data folder. This makes the connection string universal regardless of which user is publishing rather than the user specific paths that ESRI dumps way down in C:\User\<username>... when utilizing the built in "Database Connections".

Maybe give that a shot because I think ESRI reads it differently so your DB.schema.table name may be preserved.

IF this doesn't work then I'd suggest going into your model that resides in that v101 folder and checking to see the pathways being used for your inputs. I'd be willing to bet you will find that rather than the published model pointing to your valid SDE connection and table that exists within the v101 folder it's either now using %packageWorkspace%	ablename. You can edit the model and navigate to the v101 .sde file and table and the published model will re-source to use your full shared folder path, save the model and its fixed.

Sadly, can't explain why these occur just know how to quickly identify them and correct them when they do. We probably have upwards of 200 GP's across 3 environments and would say we have around 20ish that we know must be modified after publishing and have made many attempts to correct these issues with no luck yet.

MaryEllen_Perko · Answer

Hi Scott.  Thank you so much for the ideas and suggestions.  You are correct, the publishing process seems to be changing the script.  But, interesting that you say you've seen odd things when using models vs straight scripts - this is actually a model.  And not a problem we've had before our upgrade.

The uploaded/published .sde file works fine.  And the database is registered with server.  In fact, we've got many services already using it..

For testing I've created an extremely simple model that references sde data. For more information, I've attached the original model-as-script: SelectAlamanceToolFromServer.py.

And the model-as-script after publishing: SelectAlamanceCountyToolFromLocal.py

Note the drop of the sql server database and schema names in the published version.

Anyway, you've given me some ideas and information I can pass to our server administrators.  And I may try publishing this as a script instead of a model and see if it makes a difference.

Thanks again.

SelectAlamanceCountyToolFromLocal.py.zip

SelectAlamanceCountyToolFromServer.py.zip