Error 00732 from GP Service after 10.5 Upgrade

[MaryEllen_Perko]

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.

[ScottFierro2]

Can't speak to whether you are doing anything wrong or not but can say we have had a slew of issues with ESRI modifying code at publishing. Still have yet to fully pinpoint the cause but in some cases it attempts to re-write input paths and parameters fields to use things such as the %packageWorkspace% call that goes wrong when it sets that as g_ESRI_variable_1.

In most cases our anomalies we see are tied to a call that in desktop is something like arcpy.GetParameterAsText(0) that gets converted into arcpy.arcpy.u'D:\<whatever pathway>'. No clue why it modifies to the double arcpy call causing the pathway to break but have seen it a few times.

Best thing I could suggest would be from your server navigate to your servers system directory path (can be found in Server Manager under the "Site" tab). From within the arcgissystem folder navigate to arcgisinput; NCDOT_Tools; SelectAlamanceCountyTool.GPServer; extracted; v101; <find your script wherever it might be in here>. Launch your script into whatever IDLE or Text Editor you prefer and compare the published script version to your desktop script version. Any discrepancies you can correct and save here to your published version. Attempt to re-run.

I know this is less than ideal and at times this practice has allowed us to identify a slight issue in the original desktop script we can modify and then things work. Other times we simply have to document which services are known to need to be modified post publishing due to what seems to be a publishing bug. I can say this issue seems to arise more when we use a hybrid of model builder with python scripts. In pure python processes I can't say we have noticed this issue.

[ScottFierro2]

Actually, just looked closer at it appears that your process is attempting to make a call using your .sde. Sorry I didn't look more closely at the error was focused on your mention of your script.

Step 1: Is that .sde registered with the new server environment and does it validate?

Step 2: If yes, navigate to the same path I mentioned above (also seen inside the error message) and confirm that there is a copy of your .sde connection inside that v101 folder?

Step 3: If yes to #2, if you navigate to the location via ArcCatalog and launch that copy of your .sde connection does it work? Can you see the layer in question?

Step 4: If yes to #3, begin investigating your model and/or script that exists within v101 and look for publishing issues as described above in 1st response.

[MaryEllen_Perko]

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.

[ScottFierro2]

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%\tablename. 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.

[ViktoriaMagnis]

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.