Latest Contributions by KevinHibma

Upload is new at 10.1. Its a capability you can enabled on the GP Service itself. Doing this allows you to upload a file to the REST end point, and then the service can consume that file. Using this you dont have to write you own "uploader". Keep in mind if you're using this its for simple files: like a text file, or zip - it isn't meant for something like a shapefile or filegeodatabase (structures that are many files comprising 1 file) If you're using ArcMap as a client - upload doesn't really matter. ArcMap is a rich client which can send a file to gp service. If you're using a web client, see the code below (javascript) which shows how to leverage the upload capability. var gpUploadURL = "http://gizmo:6080/arcgis/rest/services/ConvertCSVKriging/GPServer/uploads/upload"; //upload the zip file and get back the itemID (via uploadSucceeded)       var requestHandle = esri.request({         url: gpUploadURL,         form: dojo.byId("uploadForm"),         content:content,         load: uploadSucceeded,         error: uploadFailed       }); function uploadSucceeded(response) {              var itemID = response["item"].itemID;                       //submit the GP Task by passing the itemID info the input parameter        var params = {'Input_Rows': "{'itemID':" +itemID+ "}" };        gp.submitJob(params, gpJobComplete, gpJobStatus, function(error){           alert(error);                 });     }     <form id="uploadForm" style='padding:4px;' method="post" enctype="multipart/form-data">        <!-- must use name="file" as Upload expects this -->       <input type="file" name="file" id="inFile" size="50" onchange="uploadFile();"/>     </form> ... View more

Not in 10.2, and no plans to the best of my knowledge after that. What these tools do, and how they work is not conducive to being used in a service. I'd say at best they would act like a scheduled task that could be modified slightly at execution time. I say this as the server will most likely have to have the MXD + Data you want to publish. It would be a pretty involved service to that gets both the MXD and all required data from the client, extracts it somehow, and then publishes. So I'm making the assumption your server already has the data/mxds on it. If thats the case, setting it up as a scheduled task would probably be more straight forward. I'm not saying these as a service cant be done - I'm just saying its something that we haven't tested and I could imagine a few areas which will be difficult to overcome. As such, I'd take the "easier" approach of just making a scheduled task. ... View more

Kaushal Shah: Right, the code is to modify the XML, thus it must go before stage. As long as the service name doesn't change, the link should remain the same. The hosted service account id is a set of letters and numbers which to the best of my knowledge doesnt change. So to the best of my knowledge, it should be ok. tribeiro: You've made a GP Service to perform this publishing routine? I'd strongly recommend against that. The Upload and Stage tools (which are required in this workflow) are not designed to be re-published in your own geoprocessing service. I'd suggest making it a scheduled task on one of your desktop machines. ... View more

Thanks for continuing to post your workflow. I just tried this and couldnt reproduce 😞 I got a fresh machine, install 10.1, sp1 + 64bit BG. I licensed as ArcView Single Use. Opened ArcMap, ran Buffer and it works. ... View more

Or you could do all the processing in 32bit. You dont have to use 64 bit Python to stop / start services. Well I can't imagine any particular code that would be 64bit dependent. Yes, Server is 64bit, but if you're making REST-Admin calls with URLLIB or something similar, the bits dont matter, its just HTTP calls. ... View more

Add the following 2 pieces into Jeff's code and it'll allow you to use UploadService (after staging of course) on an existing service (because it overwrites the service). typeReplace = 'esriServiceDefinitionType_Replacement' statePublished = 'esriSDState_Published'            myTagsType = doc.getElementsByTagName('Type') for myTagType in myTagsType:     if myTagType.parentNode.tagName == 'SVCManifest':         if myTagType.hasChildNodes():             myTagType.firstChild.data = typeReplace myTagsState = doc.getElementsByTagName('State') for myTagState in myTagsState:     if myTagState.parentNode.tagName == 'SVCManifest':         if myTagState.hasChildNodes():             myTagState.firstChild.data = statePublished ... View more

Just to be clear - you originally mention geocode service, then at the end you say geoprocessing service. I've never seen an instance that a Geoprocessing service has doubled its memory footprint. It will take on more RAM resources if you compare the footprint of just started vs. used a few times. Depending what it does it may take on different amount of resources if the execution is somewhat dynamic (that is, not all executions follow the same code path). As for the geocode service - I'm not an expert in this area, but I do know this can be a more RAM intensive service. Depending on the locator settings, the size of streets/locator, you could use up a lot of memory. It follows the same pattern of any other service. At startup it has a memory footprint and this footprint will grow some during execution. Again, I can't say for your particular situation how much it will grow, just from personal experiences I do know it can use more RAM (compared to say a Geoprocessing service). ... View more

Oh - you have BOTH Desktop and Server installed the same machine? If thats the case you have both 32 and 64 bit Python. If the last software you installed was Server, by default Python will be using 64bit. (that is if you simply double click a python script, it'll be executed using 64bit Python). You need to explicitly use the 32 bit version of Python. See this blog article - http://blogs.esri.com/esri/arcgis/2012/11/12/python-scripting-with-64-bit-processing/ - while its written for background, its true for Server as well. The short message is: if you have 32 and 64 bit versions of Python installed on the same machine, you should be referencing a specific version when executing your scripts. ... View more

As Caleb1987 said, Background, and Server as well (64-bit) will not read personal geodatabases. That said, making an ODBC connection to the .mdb may work. I haven't tested, but the biggest difference in the two workflows you're trying is the 32 vs 64 bit. I suspect you'll need to get the 64bit drivers to make this work. This KB article provides a good starting point and download links: http://support.esri.com/en/knowledgebase/techarticles/detail/32976  (make sure you get 64bit links for the Server machine) ... View more

Hmmm ...thanks for re-posting Joel. I've tried the way mentioned above (fresh machine) as well as an update. I'm still at a loss to reproduce this. If anyone is up for this - would you download Belarc Advisor from: http://www.belarc.com/free_download.html This little piece of software basically takes a snap shot of your system (hardware specs, programs installed), etc. It saves the information to a text file. If you're encountering this issue and have the ability to install, get the report and email me ([email protected]) it might prove helpful in seeing what is on your system that I dont have (which might be causing this). ... View more

Thats helpful, thanks. I believe I've tried that, but will re-do that test as well. Could you post the incident number? thanks ... View more

Thanks for the quick response, Joel. Unfortunately I'm still not sure how to get this error to appear. I'm still working on it. If anyone else has details to add, please add a post. ... View more

Has anyone submitted a tech support call? If so, could you post the incident number? I can't make this happen on my machine, and nobody here within Esri has ever encountered it, so I'd like to better understand the circumstances that make it happen. Can anyone provide further details? -What license do you currently have (basic, standard, advanced - floating or single use)? -Does your license expire? If so, is it near expiring? -This error ONLY happens with 64 bit BG installed and executing tools there? (or 32bit Background, or Foreground, or?) -Any particular tools, or ALL tools? -Do you have other Esri software installed (Engine, Server, etc)? ... View more

If you have a map service running off the same oracle data which you're trying to use in your GP service, then right: you can connect and there aren't any problems there. Nothing special comparing GP and MapServices for connecting to the database. So, that leaves a little more advanced troubleshooting. You'll either need to have ArcMap on the Server, or be able to access the servers file system from an ArcMap machine. If you can't do any of this, you'll have to copy a folder over from Server to the ArcMap machine. On the server, navigate here: C:\arcgisserver\directories\arcgissystem\arcgisinput\<service name>.GPServer\extracted\v101 (copy or connect to this folder so ArcMap has access) Inside you'll find a file called <service name>.rlt This rlt (result) is what we build and use to host the required bits of the gp service - in your case the layer(s). If you drag that into your map, it'll place an entry in the ToC and the Results window. Expand the task name (in the Toc) and you'll see a layer. This will be presumably broken. Right click > properties and check the source of this layer. >It'll be pointing to 1 of 2 places, either a location to a connection file similar to where it was published from >or a .sde connection file in the deployed input directory. (without knowing all details, I suspect this is the place it should be pointing). If the layer points to the deployed folder, now find the .SDE connection file and check its connection properties. Are they ok? Can you connect with it? I dont believe any of the above has provided you a solution, but it'll narrow down whats gone wrong. As for the .rlt, and the folders/files around it: everything is relative paths, so thats why I say connect to it and look, or copy the whole folder over. (I hope this part makes sense). Let me know what you turn up. ... View more

You have it correctly. It's just a name match. If you have "Flowlines" in your ToC, and you use that exactly in your script: "Flowlines" - when publishing, we create a layer. You obviously have it correct because you can run the tool in ArcMap. My guess is 1 of 2 things have gone wrong. Either the layer wasn't created properly in the service, or Server doesn't have access to your database to open the layer. If you do the same workflow but use a featureclass from a fGDB and do the name match in your script - does this work? If it does, I suspect it'll be a 64bit Server not having the proper client libraries to connect to the database "problem". If it isn't the connection problem, it might be a bug. If you haven't installed SP1, can you? I know we fixed a couple publishing things regarding python and publishing in 10.1 SP1. ... View more