|
POST
|
The lack of an ObjectID field, in and of itself, doesn't prevent the user from relating a table. As the Essentials of relating tables states: If you relate to a table that does not have an ObjectID column (such as delimited text files or OLE DB tables), you will not be able to apply selections using the relate. The Related Tables command from the Table window's Table Options menu will list the relate, but it will be unavailable. The Identify tool, however, can still be used to find related records. If you are being prevented from making a relate, it isn't the lack of an ObjectID field that is causing the issue. If you want to have an ObjectID field so there is more functionality with your relates, you don't have to add one to the other table. Several Esri tools work with dynamic ObjectIDs, i.e., they create a dynamic/non-permanent ObjectID field. If you are working with OLE DB connection, Make Query Table (Data Management) should work. Assuming you have a primary key for the table, the default option (USE_KEY_FIELDS) will work. Although Make Query Table and OLE DB connections should work for you, they are both older tools or ways of working with data. Query Layers (not just for spatial data) would be a more current approach to working with the data, and Make Query Layer (Data Management) also supports dynamic ObjectIDs.
... View more
01-28-2015
10:22 AM
|
1
|
1
|
1461
|
|
POST
|
You mention "query table." Are you using Make Query Table or Make Query Layer? Make Query Table is powerful, but it is an older tool, and I am not sure if its outputs are editable. I just did a quick test using Make Query Table where I took a single feature class and used Make Query Table to create a layer, so this is a very simple case without multiple data sets or joins. Although I could use an update cursor on the feature class directly, I could not use it on the layer created from Make Query Table.
... View more
01-28-2015
09:06 AM
|
0
|
0
|
2237
|
|
POST
|
Although using lists for field names is much more common, tuples are supported. I am leaning more towards the query table.
... View more
01-28-2015
08:54 AM
|
1
|
1
|
2237
|
|
POST
|
Although I don't think this is related to the error, it looks like your indentation is off on lines 03 and 04. Not sure if the code itself is that way or just a copy & paste problem into the text box. Can you post the specific error output, all of it? Knowing the line of the error is helpful, but usually additional information is output that is also helpful.
... View more
01-28-2015
08:27 AM
|
0
|
2
|
2237
|
|
POST
|
I agree with Xander Bakker, i.e., you can't remove all of the data frames from an MXD. Even through the GUI, you can remove data frames until you get down to the last one, at which point you are not allowed to remove it. If you want the border of the frame to not be visible, you can go in and change it, just not through ArcPy unfortunately.
... View more
01-28-2015
07:02 AM
|
0
|
0
|
1036
|
|
POST
|
Interesting, or oddly, IDLE on my 10.3 machine handles it fine. I am still convinced the extra error message is tied to the console where the original error message is trying to be printed. That said, I can't imagine a bit change in IDLE or Python between 10.2.2 and 10.3. As you point out, you already know how to work around the issue, which is really the most important thing. In terms of Unicode characters, it would be interesting to know why the ArcSDE errors are getting returned with a problematic character on the end.
... View more
01-27-2015
06:28 PM
|
0
|
0
|
4170
|
|
POST
|
The issue you are experiencing is likely due to your console the error messages are being printed to and not Python itself. If I run similar code in the interactive Python windows in ArcMap, it prints fine. If I run the code in PyCharm, it prints fine. If I run the code from a Windows command prompt, it generates a similar error you are seeing. My guess is that the PyScripter console is not coping with the Unicode and hence the extra error is being generated.
... View more
01-27-2015
03:40 PM
|
0
|
2
|
4170
|
|
POST
|
Unlike the MXD version of findandreplace, which ends in paths, plural, the LYR version of findandreplace end in path, singular. I am not sure whether the LYR version recursively searches or not, like the MXD version. If not, you can add some code to loop through all the layers in a layer file: layer_paths = [list of layers with paths]
for layer_path in layer_paths:
layer = arcpy.mapping.Layer(layer_path)
for lyr in arcpy.mapping.ListLayers(lyr):
lyr.findAndReplaceWorkspacePath(...)
layer.saveACopy(...)
... View more
01-27-2015
03:17 PM
|
0
|
4
|
2734
|
|
POST
|
Is something like this what you are after: layers = [list of layers with paths]
for layer_path in layers:
lyr = arcpy.mapping.Layer(layer_path)
lyr.findAndReplaceWorkspacePath(...)
lyr.saveACopy(...)
... View more
01-27-2015
03:07 PM
|
0
|
5
|
2734
|
|
POST
|
Lucas Danzinger addressed this behavior in one of his earlier replies to this thread, i.e., the locks are removed by the Python interpreter when the cursor objects go out of scope by either having the function end or having the IDE/interpreter closed out.
... View more
01-27-2015
01:44 PM
|
0
|
0
|
1856
|
|
POST
|
I am not sure why you are getting an error when you print the Unicode with the invalid character. Understanding there is an invalid character, printing the string from Python 2.7 shouldn't cause an error since the bug was fixed. That said, it would be nice if Esri's error handling was cleaner.
... View more
01-27-2015
07:32 AM
|
0
|
0
|
4170
|
|
POST
|
What version of ArcGIS and Python are you using? The known Python issue you reference affected Python 2.5 and 2.6, which the last version to ship with one of those versions was ArcGIS 10.0. I am able to print the error message without encoding changes and no crashes in ArcGIS 10.3. That said, it is odd that the error message returns an invalid Unicode character.
... View more
01-26-2015
08:26 PM
|
0
|
6
|
4170
|
|
POST
|
Unfortunately with Esri, I have reached a point of seeing is believing, regardless of what the documentation or staffers say. That said, your question is addressed in more detail in the online documentation: Compatibility of ArcGIS 10.3 for Server with earlier versions.
... View more
01-26-2015
06:43 AM
|
0
|
0
|
1319
|
|
POST
|
My guess, that table you reference simply has outdated information. Do you have a link? If you look at the ArcGIS for Desktop - Microsoft SQL Server database requirements for ArcGIS 10.3 web page, you will see that SQL Server 2014 is supported. I thought I came across a similar ArcGIS for Server page, but I can't find it now. Also, a GeoNet discussion (Microsoft SQL Server 2014 and ArcGIS 10.2.2) from this past November has an Esri staffer commenting that SQL Server 2014 support starts at ArcGIS 10.3.
... View more
01-26-2015
06:30 AM
|
0
|
0
|
1859
|
|
POST
|
Xander Bakker wrote: In addition a few comments on your code: ... it is better to use a "with" statement for you cursor, this will clear it from memory after the cursor finishes ... As much as I have advocated for using with statements with ArcPy Data Access (arcpy.da) cursors, I have come to find those cursors don't quite work as advertised when using with statements. I agree the ArcGIS Help/Documentation strongly implies what you state is how the software works: Search Cursor - Data Access module: Search cursors can be iterated using a For loop. Search cursors also support With statements; using a With statement will guarantee close and release of database locks and reset iteration. Closing and releasing database locks are guaranteed!! Those are pretty strong words. Unfortunately, they oversimplify the situation enough that I argue they wrong. I haven't gone through every type of data source, but I do know that using with statements on shapefiles leaves one lock behind while feature classes in file geodatabases leave two locks behind. The locks can be removed by explicitly deleting the cursor object, but the documentation doesn't necessarily imply that and none of the examples in the documentation show it. I have submitted a bug to Esri to either correct the cursors or update the documentation. Of course, I don't hold my breath on them doing anything about it because any end-user confusion doesn't cost them anything, you already bought the software! 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
01-25-2015
09:51 AM
|
2
|
3
|
4504
|
| Title | Kudos | Posted |
|---|---|---|
| 2 | 3 weeks ago | |
| 1 | a month ago | |
| 1 | 4 weeks ago | |
| 3 | a month ago | |
| 1 | 05-22-2026 05:27 AM |
| Online Status |
Offline
|
| Date Last Visited |
2 weeks ago
|