Latest Contributions by JoshuaBixby

The Key Error outside of the Try block is the crux of the issue.  As far as the interpreter is concerned, there is no key corresponding to the value you are giving it, so it returns a Key Error, i.e., u'B01001e1' is not key, period.  At this point, are there any differences in capitalization or white spaces?  I don't think it is an text encoding issue.  Trying printing your dictionary (print dictflds) and double checking that there is in fact a u'B01001e1' key. ... View more

A few things.  What is the error message, specifically?  Second, it seems you are naming your dictionary 'dict', which shadows the built-in dict constructor.  Although shadowing a built-in doesn't break the code, per se, it does make it more difficult to read and therefore more prone to errors.  Third, the code snippet doesn't show the dictionary object being created, is that just handled earlier? ... View more

Rudy Prosser‌, thanks for pulling this information together in one place.  Although I have been working with geodatabases for years, this compilation of geodatabase-related information will be great to share with others in our organization that are newer to geodatabases. Since 10.3 is right around the corner, get ready to update most of the links! ... View more

The functional code for recursively listing feature classes in a geodatabase is provided as ListFeatureClasses example 1 in the help for ListFeatureClasses (arcpy).  The topic was also covered in the Recursive list feature classes post at ArcPy Cafe a couple years back. For your situation, I believe the following code will work: import os ws = #path to gdb arcpy.env.workspace =  ws for ds in arcpy.ListDatasets(feature_type="Feature"):     for fc in arcpy.ListFeatureClasses(feature_dataset=ds):         arcpy.Rename_management(             os.path.join(ws, ds, fc),             os.path.join(ws, ds, '{}_{}'.format(ds,fc[:-3]))         ) The code above will rename what you have already manually renamed. ... View more

I ran this question through Esri Support:  BUG-000083762: In each cursor documentation, specify the type of lock being closed and released, as a shared lock is still present in the geodatabase after the 'with' statement executes. I can't say I am surprised, but Esri seems to be calling this a documentation bug and not a software bug, likely because it is much easier to update the documentation to say not all the locks are actually removed. ... View more

Bug BUG-000083762: In each cursor documentation, specify the type of lock being closed and released, as a shared lock is still present in the geodatabase after the 'with' statement executes. ... View more

Simply running compress on a geodatabase doesn't ensure all of the edits get pushed into base tables, unless running compress fully compresses the geodatabase.  Is the VERSIONS table showing the state ID for the Default version as 0?  Also, does the associated versioned view show all the records? ... View more

When you say "in SQL Server," are you querying against the base tables or the associated multiversioned view or versioned view?  You may only have the Default version, but the base tables don't reflect what is in the Default version unless the geodatabase has been compressed.  Since you are using 10.2.2, versioned views should be created automatically when you register the layers as versioned.  Try querying against those views and see if your missing records are there. ... View more

In your original post, you state the SelectLayerByAttribute_management tool is "an expensive transaction."  Assuming you mean expensive in terms of time, what are you using to time the tool and what are you comparing it against? Generally, I stick with the arcpy functions and classes as much as possible and use the geoprocessing tools only when necessary or beneficial.  In this type of situation, i.e., getting the bounding extent of selected features or a subset of features, I find the geoprocessing tools are faster for most of the datasets I interact with regularly. I have had success using a mapping layer and the SelectLayerByAttribute_management tool: def GetExtent(fc, sql):     lyr = arcpy.mapping.Layer(fc)     arcpy.SelectLayerByAttribute_management(lyr, "NEW_SELECTION", sql)     return lyr.getSelectedExtent() Writing simple functions and using timeit on one of my datasets with ~250,000 records, I find using a map layer and SelectLayerByAttribute at least an order of magnitude faster than a search cursor.  I can't say for your datasets, but it might be worth trying the geoprocessing tools instead of relying on a search cursor. ... View more

The complexity, size, or both of the dataset is driving whether or how tiling is being used.  If you have access to ArcGIS 10.1 or higher, you could try using 64-bit Background Geoprocessing.  The 64-bit Background Geoprocessing tools allow for much more RAM to be utilized, which could change or eliminate tiling and get you the results you are after. ... View more

Tile processing of large datasets was introduced in ArcGIS 9.2 (well, it could be done in 9.1, but it was more manual and not integrated or automatic).  Even without looking at the Help, the progress window for the Union tool shows there is tiling occurring: Maybe there were not enough qualifiers on your statement about the Union tool and new vertices because the Union tool has to add new vertices in many cases: If your statement was meant for self unions, then I agree that new vertices seem spurious. What steps are you using to find the extra vertices? I am running ArcGIS 10.2.2 with all but the last couple patches, and I did find extra vertices.  I only closely looked at a handful of the extra vertices, but they were all duplicate vertices.  If it turns out that all of the extra vertices are duplicates, then there is no difference in the geometries of the polygons, well the perimeter and such. The reason I asked what steps you took to find extra vertices is that I used the Feature Vertices to Points tool.  Without doing more digging, I can't say whether the issue resides in the Union tool or Feature Vertices to Points tool. Beyond the tools, have you checked how clean the polygons are?  Looking at a few of the duplicate vertices, they seem to be near areas where the polygons seem to be self intersecting, or really close. ... View more

Do you have access to the SDE schema tables?  Have you looked to see if there are possibly entries for the view even though it doesn't exist?  Have you tried creating the view with a slightly different name?  I know in the past, if I had an mv_view that I didn't clean up completely, I would sometimes get this error message when trying to recreate the view. ... View more

Vince Angelo‌, I remember that blog post.  It was quite interesting and good material to be referenced and looked at in relation to this discussion.  I very much look forward to seeing some of the ideas discussed in that blog post come to fruition, understanding they are side projects of course. The reason I linked to that thread in the SQL Server Spatial Forum was that I thought Jakub K's recursive-quartering tessellation scheme was fairly elegant, and quite simple to implement through a couple table-valued functions.  From what I have seen, the geoprocessing/spatial functions in question do seem sensitive to vertex count, so reducing vertex count definitely helps. For most datasets, maybe tessellation is overkill and gridding will suffice.  For one of the datasets I was working with, that wasn't the case.  Looking at a gridding scheme and recursive-quartering tessellation scheme that both generate similar numbers of partitions for one of the complex polygons in my dataset, one can see how the tessellation balanced out the number of vertices better. Balancing out the vertices better allowed for the next part of the geoprocessing/spatial functions to execute quicker.  Using just the DBMS, no RAM caching, the recursive-quartering tessellation scheme got me in the range of 0.5 ms/feature while the gridding scheme was closer to 1.5 ms/feature.  I admit I didn't spend much time on optimizing a gridding scheme, so there is likely room for improvement there, but I am not sure if a more efficient gridding scheme alone will do much better than the current overall performance of using the tessellation scheme. I am pretty content with 0.5 ms/feature, and Jakub K's tessellation scheme got me there, so I thought I would share.  I know there are techniques that can get even better performance, but for now that extra investment isn't necessary for my situation. ... View more

I bit more information about the database would be helpful.  For example, what version of SDE and what DBMS and version?  Also, are we talking about two feature classes in the feature dataset?  A feature class and a table?  What command and syntax are you using to try to create it from the command line? ... View more