AnsweredAssumed Answered

SDE Connections Get Duplicated When Publishing Geoprocessing Services

Question asked by MollyKFoley on Mar 28, 2018
Latest reply on Nov 6, 2018 by martinwong

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.

Outcomes