Latest Contributions by KevinHibma

‎09-21-2012

Ok cool. I'm glad you're off and running. And thanks for the info - I'll use it here to see if I can reproduce whats happening to better understand why its not behaving like it should.

‎09-21-2012

Well we dont scan any imported scripts, so the fact it imports a 3rd party module wouldnt have any impact on it. Based on your explanation and code, this should be working. Nothing you've said stands out as strange to me. Well - the published script you're looking at inside the arcgisinput directory: it doesnt have at the very least a new header of #esri added variables#? I'd expect to see at least that. Would you be willing to re-work your script ever so slightly to see if this works? Make a folder at the same level as your ADSSurface.py called "scripts" Move your GetSurface.py script in there. Then add the sys.path.append into your script (shown below) I know that this will copy over everything in the "myPythonModules" folder. Because of sys.path.append, when it gets moved to the server, the paths will line up. import arcpy, os, sys myPythonModules = r'e:\<directory where ADSSurace.py lives>\Scripts' sys.path.append(myPythonModules) from ADSSurface import ADSSurface fieldId = arcpy.GetParameterAsText(0) year = arcpy.GetParameter(1) surface = ADSSurface(fieldId, year) raster = surface.getRaster() arcpy.SetParameter(2, raster)

‎09-21-2012

Yes, see this topic: http://resources.arcgis.com/en/help/main/10.1/#/Authoring_geoprocessing_tasks_with_Python_scripts/00570000007r000000/ Specifically the "Importing other Python modules" section

‎09-17-2012

There might be a more eloquent solution than this....but off the top of my head r = arcpy.CreateArcSDEConnectionFile_management("c:/temp","sde","ffoooo","411","SQLSERVER","DATABASE_AUTH","sde","*****","SAVE_USERNAME","#","SAVE_VERSION") msgIndex = 0 while msgIndex < r.messageCount: if r.GetSeverity(msgIndex) == 1: if '000565' in r.getMessage(msgIndex): print "cant connect" sys.exit() msgIndex +=1 # if you get this far, assumed connection is made...

‎09-13-2012

My apologies, based on my testing, this appears to be a bug in 10.1 final. That said, it doesn't reproduce on 10.1 SP1 (which is currently undergoing final testing and will hopefully be available for release within the next 2 months). At this time I can provide you with 2 workarounds to the issue: 1) Modify your code to something like this: import arcpy if __name__ == '__main__': fc = arcpy.CreateFeatureclass_management(arcpy.env.scratchFolder, "fc1", "POINT", "", "DISABLED", "DISABLED", "", "", "0", "0", "0") arcpy.Delete_management(fc) This no longer puts the output to the in_memory workspace, it now puts it to disk (a folder) - but will publish successfully. This is the easiest most straight forward workaround. 2) If you want to continue to write to in_memory, you'll have to modify your script and parameters a little bit. import arcpy if __name__ == '__main__': inWorkspace = arcpy.GetParameterAsText(0) fc = arcpy.CreateFeatureclass_management(inWorkspace , "fc1", "POINT", "", "DISABLED", "DISABLED", "", "", "0", "0", "0") arcpy.Delete_management(fc) >> new parameter in the first position (0-indexed) of type string, with input value of "in_memory" Then.... you run this, get your result and publish. When inside the Service Editor (publishing your service), go to that parameter (in this case, the first one), and change the Input Mode to "constant". This hardcodes it and the user of your service doesnt set it and your tool will continue to use in_memory. I understand neither are ideal, but they'll move you forward till SP1 is available. edit: The bug information is: NIM084303 - When publishing a simple script that references the "in-memory" workspace, the analyzer says the "Data source used by Script is not registered with the server and will be copied to the server: in_memory." Then the publish will fail to create a service definition.

‎09-10-2012

Hi again, you mean the Value List in the Feature Format parameter causes the problem? Because it uses the string ".gdb"? That's why it's looking for a data source named "gdb"? Well, thanks for the hint! I can hardcode-limit this to .shp only until SP1 is available. I'll give it a try and post my results. Steffen. exactyl! 🙂

‎09-10-2012

No, we dont do "beta" service packs, only the final release of them. If you absolutely require a custom version of the extract data task, do you still need feature parameter input? This is the problem, if you can either hardcode or change that parameter, you can probably get around the analyzer problem. The tool does a name match, so its possible (i havent tried this though) to play with the name inside the parameter and then change the code in the tool. Of course if you dont need the feature type parameter, the best solution would be to hardcode it in the script and not expose that parameter. Again, I think this will work, but no guarantees.

‎09-10-2012

No, you dont need to do that (and actually shouldnt) - For a second I got my analyzers mixed up and was thinking about another one. Its good you confirmed that though. To my knowledge, this analyzer which is impeding your publishing does not break into function tools to inspect them. I'm a little unsure how/why 151 would be thrown on a function tools. Is there any chance you could share your compiled tool with us? I'll give it a try here. Again, this is strange, we have a test with a custom tool that does almost exactly what yours does and works without issue. I cant comment on the license code, but dont suspect thats an issue, again because this analyzer isn't digging into the tool (I think). If you can share the dll, please zip it up and send to me ([email protected]). thanks

‎09-10-2012

Steffen, Thanks for the detailed steps. Using steps 6-11, on a ArcGIS 10.1 final machine I can reproduce the issue. Using a 10.1 SP1 machine (we havent released SP1, we're finalizing it right now), I cannot reproduce the issue - so we've fixed it. My apologies for the inconvenience. A question though - why do you need to copy the script and model tool to a custom toolbox? If you want to control parameters (for example, you want to remove options from the feature choice list, or you dont want to expose the raster format parameter) you can run the tool from the system toolbox, and then during publishing modify those parameters inside the service editor. Just click the parameter name on the left hand side and change the Input Mode, or configure the Choice List options. Unless you're adding new values to the data extract format task, everything else you want to do should be configurable through the service editor. I hope this will provide a suitable workaround till SP1.

‎09-10-2012

I understand you reluctance to get into Python scripting - you can do this in a model, but will need to put some python code into Calculate Value to get the result you want. So for this particular problem, no matter how you crack it, you'll need to write either a little code, or a "little more than a little". Heres how I was able to do it using a model and a little bit of Python code: -Iterator over featureclasses -Parse Path (model only tool) which gets the full path to the featureclass you're working with -Calc Value (which is where the Python code will be used to "find" the featureclass name") -FeatureClass to Featureclass to copy the features into your single GDB [ATTACH=CONFIG]17572[/ATTACH] Here you can see the code inside calc value. Theres 100x different ways to parse a path in Python, this is just one way (kind of the long way, but I wanted to make the example clear). [ATTACH=CONFIG]17573[/ATTACH] expression getName('%Value%') code block import os def getName(inPath): sName = inPath.split(os.sep) gdbName = sName[len(sName) - 2] finalName = gdbName.strip('.gdb') return finalName data type String I hope this helps.

‎09-10-2012

I'm not trying to hi-jack this, only offer advice/questions on the error 151: This is a function tool - but have you wrapped it inside a script tool some how? Or are you actually running the function tool?

‎09-10-2012

This shouldn't have anything to do with the ExtractData script, nor matter if its embedded or not. The analyzer error 00068 says that the packaging/publishing process cannot find required data to complete publishing. (broken project data required for the service) I've never seen that error pop up in regards to the Extract Data task. We'll bang on it here to see if we can reproduce it, but I'm sort of at a loss as why thats happening for you. Instead of publishing as a service, can you save it as a geoprocessing package - same error, or no? Can you very clearly spell out your workflow? (maybe you're doing something I'm not...?) thanks

‎09-07-2012

I believe you can use %n% to grab the iteration number. I just tried it and it works. So my final output looks like: c:\temp\f.gdb\%Name%_%n% Alternatively, take a look at the 2nd code sample at the bottom of the KML to layer page. It demonstrates converting a bunch of KMLs into featureclasses, then pulling each featureclass out of their respective GDB, and into a single GDB and assigns them the name from the GDB they came from (not placemark). This sounds similar to what you're trying to do. http://resources.arcgis.com/en/help/main/10.1/index.html#//00120000004w000000

‎09-05-2012

If you've stopped and re-started the ArcGISServer service in the Services panel, and memory didnt change, then the process sounds either hung or orphaned. When you restart they should all disappear and then come back fresh. After re-starting my server I have: 2 javaw.exe 1 arcgisserver.exe X # of ArcSOC.exe I'd expect you to have something similar. I cant give you a yes/no answer on how much memory should be used. I don't concentrate on the core architecture and wouldnt want to give you a wrong answer. Just my impression though, 1 gig (1,000,000KB) sounds high for the javaw.exe process, but without knowing exactly what your server is doing, # of requests, # of services, etc - its hard to say if thats a problem. The biggest change which I'm sure you're aware of is 10.1 being 64bit, so each process can potentially consume more memory than 10.0 -32bit server. Just a tip, which may or may not be useful in this situation: If you goto Task Manager, and under VIEW > Select Columns. Turn on "Command Line". In the processes tab you can then see in for each ArcSOC.exe process which service it is running. The name will be found at DService = "...." This might be useful in helping to identify which services require more memory than others and planning deployment.

‎09-05-2012

I'm not 100% sure of this, but I think one of the javaw.exe is for logging. Do you have logging set to a high level? If you set it back to a low level (like SEVERE), and re-start ArcGIS Server, it shouldnt be as active.

Online Status	Offline
Date Last Visited	‎03-25-2026 08:04 AM

My Ideas

Latest Contributions by KevinHibma

Re: Publishing dependencies with custom tool to server

Re: Publishing dependencies with custom tool to server

Re: Publishing dependencies with custom tool to server

Re: Determine if SDE Connection is Available

Re: publishing a geoprocessing service that references in_memory data to AGS 10.1 fa

Re: 10.1 ExtractData.py script not the same as embedded Extract Data tool script

Re: 10.1 ExtractData.py script not the same as embedded Extract Data tool script

Re: Deploying a Custom C# GP-Tool on 10.1 Server

Re: 10.1 ExtractData.py script not the same as embedded Extract Data tool script

Re: Inline Variable Substitution in ModelBuilder Question

Re: Deploying a Custom C# GP-Tool on 10.1 Server

Re: 10.1 ExtractData.py script not the same as embedded Extract Data tool script

Re: Inline Variable Substitution in ModelBuilder Question

Re: 10.1 Memory Issues

Re: 10.1 Memory Issues

Re: Notebook Server 11.5 Webhook Receivers

Re: Notebook Server 11.5 Webhook Receivers

Re: Feature service webhooks error at 11.0

Re: Enterprise server referenced feature services ...

Re: Webhook URL update for Power Automate