AnsweredAssumed Answered

Publishing PYT with a string pointing to an SDE file on disk crashes ArcCatalog

Question asked by mleahyesri-ca-esridist Employee on Dec 10, 2012
Latest reply on Dec 14, 2012 by mleahyesri-ca-esridist
Hello all,

I have encountered a new problem. Consider the code snippet below. This code can be dropped into any Python Toolbox (*.pyt) in place of the execute() function. All it is doing is assigning a plain text string that contains a file path to an sde file on disk. The same value is assigned on two different lines. In the first case, the value is all in one string, while in the second case, it is broken apart.

Either line works fine when running the tool in ArcGIS desktop. However, if I attempt to publish the result of the tool to ArcGIS server, ArcCatalog crashes completely, with presenting the dialog for reporting a problem. If that first line is excluded, and/or if the path does not match the location of an existing sde file, then publishing the will work fine.


def execute(self, parameters, messages):
 
  ### Declaring a text string that points to an existing *.sde file on the local
  ### disk will cause ArcCatalog to crash when attempting to publish
  ### a result from running this tool as a GP Service
  myGeodatabase = "C:/Data/test.sde"
 
 
  ### The following approach seems to
  ### workaround this for now:
  myGeodatabase = "C:/Data/"+"test.sde"
 
  return


I'm guessing this may have something to do with the way that ArcGIS 10.1 keeps track of references to data on disk, and aligns these with databases/folders that are registered on a ArcGIS server that I'm publishing to. If that's the case, then I would imagine that the workaround I show is tricking the publishing service into overlooking the reference to the sde file. However, even if I have both the database connection and the folder that contains the sde file registered as data sources on the server, the publishing service will still crash.

Has anyone else encountered this kind of problem, and/or is there something particularly wrong that I'm doing with this? Perhaps there is a better method to handle references to local data - would anyone have suggestions on that? It doesn't make sense in my case to have the location of the sde file exposed as a parameter in the GP tool, as client applications will not be aware of this...nor would I want clients to supply the location of a different sde file on the server.

Outcomes