I'm taking one last stab at an answer for this - has anybody had this happen before? When I publish a geoprocessing service that involves an SDE connection file, it copies that SDE connection file to the server (this is expected behavior) but then duplicates that connection down in arcgisserver/directories/arcgissystem/arcgisinput/../../extracted/v101 folder. I cannot figure out why it's doing this and I have tested everything I can possibly think of to see if it'll stop duplicating the connection file but it won't. It does this with any database connection and it does it no matter where the SDE file is stored on the publishing machine. The service works and it's the exact same database connection, so I'm not sure how much it matters, I just find it really weird and would like to understand it! The only thing I can think of at this point is that it's because I'm publishing a GP server from Desktop 10.6 to AGS 10.4.1.
This simple script published as a GP process yields this in the above-mentioned directory:
import arcpy db_con = r"C:\Users\xxx\AppData\Roaming\ESRI\Desktop10.6\ArcCatalog\HbMonitoringTest_nbcidb_HabitatTestWriter.sde" arcpy.AddMessage(db_con) if arcpy.Exists(db_con): arcpy.AddMessage("your db connection worked") else: arcpy.AddMessage("your db connection sucks")
The script that resides on the server once the GP service is published references the duplicate (HbMonitoringTest_nbcidb_HabitatTestWriter1.sde) and not the original.
You'll notice that there are two different dates/times listed for each of the SDE files; I created a database connection to the one without the 1 appended to the end yesterday, so when it copies this file to the server, the metadata (date/time) come with it and are not updated to reflect today's date since it's simply a copy. Once it's on the server, I guess it must duplicate it, hence why the file with a "1" appended to the end has the current date/time. I have outright deleted the GP service, made sure all the files are gone in the directory, and then republished from scratch to assure myself that there aren't two different files simply because one wasn't overwritten. That's not the issue.
I'm tempted to roll back to Desktop 10.4.1 just to see if this issue goes away because I am out of ideas.
I see the same thing publishing from Desktop 10.6 to Server 10.6.
This looks like a bug to me. If instead of publishing you stage the service (copying data), the service analyzer throws an error like:
SEVERITY STATUS CODE DESCRIPTION NAME TYPE
High Unresolved 00068 Script Script contains broken project data source: C:\Users\xxx\AppData\Local\ESRI\Desktop10.6\Staging\server on mymachine.esri.com (admin)\0\v101\connectionfile1.sde Script Tool
I don't have a connectionfile1.sde. I just have a connectionfile.sde
I have an issue open with Esri Support. From where I'm sitting, the issue is actually a little more severe. If I attempt to stage a GP service, using the option to copy data into the service definition, Desktop looks for that invalid .sde connection file and fails to stage the .SD. I'll follow up with the bug # once they've logged it.
I was having a similar problem and also getting the broken project data source error message. I finally got around it by adding the SDE connection file as an input parameter and then joining it to my feature class name:
## Input for the connection file C:\Temp\Prod_Land.sde conn = arcpy.GetParameterAsText(0) ## Using the join method to ensure for correct path delimiters tree_lyr = os.path.join(conn, os.path.join(r"trees_prod.dbo.Trees"))