Latest Contributions by BlakeTerhune

‎01-30-2015

So what would happen if the same ID had five different owners? Or ten different owners? You'll just have to keep increasing the number of columns to accommodate the most duplicated ID. Sounds like these are not duplicates but rather you have two key fields. I wouldn't try making extra columns for the additional owners because it will get messy. Is there some kind of dependency requiring you to format your data like this? In your example, do each of the three objects also have different geometry/location? If the geometry is the same, maybe you could consider using a related table so you can have one object with one ID related to an owner table that has three records with the same ID and each different owner.

‎01-27-2015

You may be right, possibly something with my version of Python and the place I'm running it from. I'm not sure how to run it from Windows Command Prompt so I just tried it in IDLE and still get the same error. Here's how I'm running it import arcpy try: sdeconn = r"C:\GISConnections\SDE@GTEST.sde" sql = "SELECT * FROM INVALID_TABLE" cnxn = arcpy.ArcSDESQLExecute(sdeconn) sqlresult = cnxn.execute(sql) for i in sqlresult: print i except Exception as err: print unicode(err.message).encode("utf-8") ## Successfully prints Esri error message print err ## Throws Python error finally: # Cleanup if 'cnxn' in locals(): del cnxn Thanks for your persistence, Joshua. At least I know how to handle the error for now. I'll just hope it will go away after the next ArcGIS upgrade we do.

‎01-27-2015

Before opening the search cursor, could you check to see if any features are selected? If there are selected features, continue to use search cursor; If not, handle exception. Assuming it is a layer, here's the direction I would go. I have not tested this. You may have to check for a length like len(desc.FIDSet) > 0 desc = arcpy.Describe(manhole_layer) if desc.FIDSet: # Do something with selection with arcpy.da.SearchCursor(manhole_layer, "*") as cursor: for row in cursor: print row else: # Handle Exception print "No features selected."

‎01-27-2015

I did some quick testing here and I confirmed what Luke found: running the with statement in a function removes the locks while running it alone (outside a function) leaves the locks. However, if you run the with statement outside of a function, the locks only remain until you close the IDE (I was using PyScripter). Same thing if you just run the .py file with python.exe, the locks are removed when the script has finished running.

‎01-27-2015

UPDATE: I am on Win7 64-bit with ArcGIS 10.2.2 using PyScripter for Python 2.7. I can confirm that running the with statement inside of a function like this will remove the locks in a file geodatabase when done (did not test shapefile). import arcpy def main(): fc = r"C:\TestData\TEMP.gdb\TEMP_FC" fields = ["*"] with arcpy.da.SearchCursor(fc, fields) as cursor: for row in cursor: print(row) if __name__ == '__main__': main() If you run the with statement outside of a function, the locks remain after the script has completed. I even tried using arcpy.ClearWorkspaceCache_management() import arcpy fc = r"C:\TestData\TEMP.gdb\TEMP_FC" fields = ["*"] with arcpy.da.SearchCursor(fc, fields) as cursor: for row in cursor: print(row) However, I also noticed that the locks go away once you close PyScripter! Same thing happens if you just run the .py file with python.exe, the locks go away when the script is finished running. So this is really only an issue when running code inside if the IDE. Either way, it's probably good practice to have your code in a function anyway.

‎01-27-2015

I was intrigued by your post and stumbled across this thread. In it, Lucas Danzinger of Esri found that if the with statement was run inside a function that the locks were released correctly. He also logged this under Bug NIM-089529. Re: Python WITH statement does not release da cursor schema locks I have not tested this yet.

‎01-27-2015

This Python document mentions the issue of printing Exceptions with unicode characters but it's just generically directed at Python 2.x

‎01-27-2015

I'm using PyScripter for Python 2.7 with ArcGIS 10.2.2 (which I believe ships with Python 2.7.5).

‎01-26-2015

If you execute an invalid SQL statement with arcpy.ArcSDESQLExecute(), it will return an error message with a unicode special character (see ArcSDESQLExecute_Error.gif). That unicode character in the error message actually causes an error with Python if you try to print the message (see PythonUnicode_Error.gif). Apparently this is a known Python issue. I found you have to wrap the arcpy error message up in encoding so Python doesn't choke (haha). except Exception as err: raise Exception(unicode(err.message).encode("utf-8")) Why is this silly unicode character in an error message anyway? Has anyone else found a better way to deal with this?

‎01-26-2015

Thank you Joshua, I appreciate your reply. I'll try running SDEMON from the Windows Server like you suggested. We will continue testing and I'll post back if there are any significant developments.

‎01-23-2015

It installs with a different shortcut for each Python version. Do we need to make sure we are running the PyScripter for Python 2.7 so it's "compatible" with ArcGIS? I seem to remember something about this being the case.

‎01-23-2015

We have a database maintenance Python script (very similar to this one Esri recommends) and it kills all users with arcpy.DisconnectUser() before performing maintenance operations. This script is executed by Task Scheduler on Windows Server 2012 r2. Our ArcSDE 10.0 run on Oracle 11g on a Linux server. Here is an older, similar discussion‌ that ended in a suggestion to enable TCPKEEPALIVE. What we've found is that when the script kills all users, all connections in the SDE.Process_Information table go away (as expected) but the associated database/os process for each connection (gsrvr) remains. This is a problem because they build up and eventually hit the limit set in the Oracle initialization parameters. With further testing, we found that running the kill all users SDEMON command locally on the Linux server would kill the connections and clean up all associated gsrvr processes and sessions. We are currently testing two possible solutions: Enable the TCPKEEPALIVE setting to hopefully find and kill the orphaned processes. Instead of using arcpy.DisconnectUser(), run the SDEMON command through Plink in Python using subprocess.Popen() My questions are: Is this possibly a bug with SDE/Python? Is TCPKEEPALIVE a sensible option to solve this problem? With SDEMON depreciation, will the Python Plink command option be a good long-term solution?

‎12-29-2014

When working with dictionaries, I found it helpful to iterate the items rather than the generic dictionary so you can name the key and value to be more readable. import arcpy import os # Environment variables sourceGDB = r"C:\temp\source\source.gdb" outputGDB = r"C:\temp\output\output.gdb" # Feature classes dictionary ## Key is destination feature class name (out_lyr) ## Value is source feature class name (in_lyr) layers = { 'myOutputPoints': 'sourcePoints', 'myOutputLines': 'sourceLines', 'myOutputPolys': 'sourcePolys', } ## End layers # Export feature classes in dictionary for out_lyr, in_lyr in layers.items(): arcpy.CopyFeatures_management( os.path.join(sourceGDB, in_lyr), os.path.join(outputGDB, out_lyr) ) print "{} copied".format(out_yr) # write geoprocessing warning messages if arcpy.GetMessages(1): print arcpy.GetMessages(1) I also like to use arcpy.ClearWorkspaceCache_management() to cleanup all my scripts with that connect to SDE.

‎12-29-2014

Love it! Thanks for taking the time to put this together.

‎12-26-2014

I think the scratch workspace still needs "physical" drive space to work, even if it is just temporary. This is different than in_memory workspace. Since you just got access to your ArcGIS Server Manager, you might need to make sure that the user account running the operation using scratch workspace has write access to the directory on the server. If your admin won't allow general access like that, see if you can create a new directory just for scratch work and give you full admin rights to it. Then make sure the scratch workspace environment is set to that directory. I haven't tried any of this, I'm just offering up some ideas...

My Ideas

Latest Contributions by BlakeTerhune

Re: Arcpy - search duplicate attributes, then update values

Re: ArcSDESQLExecute error message contains unicode character

Re: arcpy.da.searchcursor with nothing selected returns all records

Re: Python WITH statement does not release da cursor schema locks

Re: square buffer

Re: square buffer

Re: ArcSDESQLExecute error message contains unicode character

Re: ArcSDESQLExecute error message contains unicode character

ArcSDESQLExecute error message contains unicode character

Re: arcpy.DisconnectUser() run from WinServer to SDE on Linux w/ Oracle does not kill associated OS process

Re: Python error question

arcpy.DisconnectUser() run from WinServer to SDE on Linux w/ Oracle does not kill associated OS process

Re: Some Python Snippets

Re: Some Python Snippets

Re: very simple: how do i get "analysis" tool to run as a service?

Re: ArcGIS JS API 3.x CDN Lifetime

Re: ClearWorkspaceCache: For Your "This Should Wor...

Re: ClearWorkspaceCache: For Your "This Should Wor...

Re: Iterating through geometries in a layer for mu...

Re: Iterating through geometries in a layer for mu...

Python Snippets

Experience Builder Tips and Tricks

GIS Jobs

ArcGIS Arcade