Arcmap claims data source is different when it isn't

[JonMorris2]

I'm trying to publish a GP result and the analyser gives the following error:

SEVERITY	STATUS	CODE	DESCRIPTION	NAME	TYPE
High	Unresolved	24032	Data source used by Script LFP Setup Basic is not registered with the server and will be copied to the server: C:\Users\jpm\AppData\Local\ESRI\Desktop10.2\Staging\arcgis on ls8-xxxx_6080 (admin)\0\v101\ls8-xxxx.sde	LFPSetupBasic	Tool

The data source is hard coded into the script:

INWorkspace = r"Database Connections\ls8-xxxx.sde"

The question is, why does Arcmap think this data source is different? I have registered this GDB on the server and have published a few scripts over the past few days without problems. Is it matching on just the sde file path? I've had problems in the past where a connection file name had different case, so was flagged as a different datasource, even though the connection details were the same. Why can't Arcmap open up the file and compare the connection details instead?

[PaulDavidson1]

What happens if you use an absolute path?  a UNC path?

And are you publishing directly on the server or from a remote desktop?

We usually register the data with full paths on the server and then publish directly on the server in order to avoid having the data re-copied.

[JonMorris2]

I'm publishing directly. Absolute path works, but I didn't think hardcoding that would be a great idea. Haven't tried UNC path.

I think Desktop is doing some odd caching, as it also complained the script had a broken data source. It was expecting a copy of the connection file to be in the staging folder, but it wasn't. After I restarted ArcMap, it all worked properly again, so it must have got itself into some weird state.

[PaulDavidson1]

That's interesting about the potential caching problem.

I do know that often when I have the problem you first described, if I step back and look at the path from the server's perspective, I sometimes realize I've made assumptions or that it might be difficult or impossible for the server to actually see that path.

We've had the best success with registering data on the server and then publishing the mxd from the server itself rather than via an ArcMap connection from a desktop. It just removes one possible level of confusion or interpretation.  For example, ArcMap on my desktop expects connection files in one place while our ArcServers expect them in a totally different location (the two environments have different default perspectives.)

Best of luck, did your restart of ArcMap clear up your original problem?

It is unfortunate that this issue is not simpler and that the publisher isn't wiser because wrapped up data doesn't end up in a very useful place.

[JonMorris2]

It's hard to say if the problem is cleared up, because up to now it's been fairly intermittent. Let's say I haven't seen it since restarting ArcMap.

I also tried putting the connection file on a network share and coding a full UNC path in the script. It worked like a dream, so that's the approach I'll take from now on. Thanks.

[JonMorris2 · Accepted solution]

Finally got to the bottom of this one:

I always run my GP tools from Arcmap and have the GP option 'Add results of geoprocessing operations to display' enabled. It seems to be that having the result rasters added to the TOC is confusing the analyser and making it erroneously claim that the datasource is not registered.

So, there are 3 possible workarounds:

1. Use ArcCatalog
2. Turn off the 'Add results to display' option
3. Leave it turned on, but delete the layer from the TOC before publishing