Published GP Service keeps copying data to server

4787
22
12-18-2012 06:25 AM
ZacharyHart
Occasional Contributor III
I almost put this in the AGS 10.1 General section, but landed here.

So just like the title says, not matter how I try, when I publish my GP service (results from a model) the relevant SDE data gets copied to the server down in \\servername\arcgisserver\directories\arcgissystem\arcgisinput.

The SDE DB is registered with the GIS server and no warning/messages appear about copying data at the time of publishing. I've been through tech support and the incident was escalated. The model is very simple....essentially moving selected features from one FC to another via append. The GP service runs successfully on the server but appends to that fGDB copy that resides on the server. Is this expected behavior?
0 Kudos
22 Replies
ZacharyHart
Occasional Contributor III
Kevin, trying to read more on the article you provided....can only see the top of the section you refrence. Sadly, my Droids browser never let's me scroll down on ESRI help entries....and only ESRI help entries....no other site....oh well.
0 Kudos
ZacharyHart
Occasional Contributor III
I can read till 'regardless'.....what a drag.

ok, now with a 'real' browser i can read the rest of what Kevin posted. It seems to suggest that at 10.1 GP services copy data to the server no matter what?
Even then, my problem is still with the published model. The output references that file gdb published to the server, not my SDE connection.
0 Kudos
KevinHibma
Esri Regular Contributor
I can read till 'regardless'.....what a drag.

ok, now with a 'real' browser i can read the rest of what Kevin posted. It seems to suggest that at 10.1 GP services copy data to the server no matter what?
Even then, my problem is still with the published model. The output references that file gdb published to the server, not my SDE connection.


No... it will only copy the data if it doesnt find a match in the datastore.

If you can publish a map service and that data doesnt get copied, then the datastore is setup correctly.
I've never heard anyone report this particular issue you're running into: not warned about data being copied, but then the data is copied.

You said you logged a support incident? Whats the incident #? I want to look up the notes and see if anything stands out.
0 Kudos
ZacharyHart
Occasional Contributor III
No... it will only copy the data if it doesnt find a match in the datastore.

If you can publish a map service and that data doesnt get copied, then the datastore is setup correctly.
I've never heard anyone report this particular issue you're running into: not warned about data being copied, but then the data is copied.

You said you logged a support incident? Whats the incident #? I want to look up the notes and see if anything stands out.


sent you a PM
0 Kudos
ZacharyHart
Occasional Contributor III
UPDATE:

soo another phone session this afternoon, and tried many things before that. Here's what i've got so far:

  • No matter how hard I try, when publishing a GP service the data copies to the server

  • When you review the published copy of the model on the server it refrences the server's copy of the data

  • You can modify the model to reference the correct SDE connection to your feature classes and restart the service and it will work correctly

  • The only way the modified GP service will work is against a map service referencing the same SDE features; if you try the published GP service against the local connection to the SDE data, it completes without warning and no results are depicted/appended. This was replicated via executing the GP task at REST; if the feature being accessed the task ran but produced no results; if no connections were active to the feature the rest service was able to write/append to the SDE FC just fine.

  • I can publish a map service with feature access capabilities against the same data set and it publishes without copying any data just fine

  • i can access the map service and run the gp service against it and it works just fine (see above)

  • If I attempt to add the feature service from the TOC to an arcmap session it instantly crashes with no error

  • If I expose the feature service via a web application it works fine (last I checked anyway)



So this may need to be moved over to the arcgis server 10.1 forum. I dont know but i'm ready to just give up...it will be nearly a week since it was escalated and nearly 2 weeks since the initial problem was discovered and the incident was initiated. I'm just so completely at a loss.
0 Kudos
ZacharyHart
Occasional Contributor III
Any other ESRI staff want to take a shot at this? its been weeks now and I still dont have an answer from the escalated incident.
0 Kudos
AndrewChapkowski
Esri Regular Contributor
If you install 10.1 SP1, you can set the server to block all data copying.  Check out this: http://resources.arcgis.com/en/help/main/10.1/#/Example_Prevent_data_copying_at_publish_time/0154000...

This might help your issue.

To do this without python, you can follow these instructions: http://resources.arcgis.com/en/help/main/10.1/#/Disabling_automatic_data_copying_when_publishing_to_...
0 Kudos
ZacharyHart
Occasional Contributor III
[#NIM087822  GP service using feature class from sql express workgroup sde will have data copied to the server even the gdb was registered with server data store. ]
[#NIM087819  Feature service shows no editable layer error when the feature class was from workgroup sde (sqlexpress) with OS authentication ]

That is right, it basically makes feature service not editable when using sql express in server 10.1.


This is rather profound IMO.
0 Kudos
KevinHibma
Esri Regular Contributor
I can't reproduce this (I'm responsible for testing NIM087822 and assigning to a developer).

If you have a minute can you look at the attached word doc. Is there anything you've done differently compared to my workflow?
If there is indeed a bug here (as I've done something differently than you), I'd like to get it addressed for the next service pack. However that window is quickly closing so any information you can provide would be great.
0 Kudos
ZacharyHart
Occasional Contributor III
I can't reproduce this (I'm responsible for testing NIM087822 and assigning to a developer).

If you have a minute can you look at the attached word doc. Is there anything you've done differently compared to my workflow?
If there is indeed a bug here (as I've done something differently than you), I'd like to get it addressed for the next service pack. However that window is quickly closing so any information you can provide would be great.


The analyst was able to reproduce this. The there is no warning that the data will be copied to the server; the sde connection file is not copied to the server, an extract of the SDE data is copied to the server arcgisinput directory as a fGDB.

Permissions are set for the local arcgis account (i even reset the password to all arcgis accounts to be sure this wasn't an issue); and i tried both registering the db server directly, the SDE connection file as you show, moving the SDE connection file to several different physical locations to see if registering it then would return different results etc etc. I looked from the SQL mgt studio side of things with the analyst too to ensure the local account was being used correctly by SQL Express and still no luck. Perhaps you can contact the analyst who worked on this, we spent several weeks trying to diagnose this so he probably has extensive notes.

My suspicion had been that there was an environment setting error, but the analyst did not believe that was the case. The tool worked fine locally, and if we modified the published tool on the server to use the correct data sources it would work then, but as i recall, only work when consumed via a web application, not desktop.
0 Kudos