When I run the Make XY Event Layer tool, my event layer table is created with two Shape (both point) fields. This prevents me from being able to export the layer to a shapefile, as the export fails because of the multiple fields. It does no good to turn them off before exporting - actually one of the fields does not turn off or on, and turning the other one off or on adds or removes both of the duplicate fields. Has anyone run into this? There was a thread on this same issue several years ago, but no resolution. Any help would be appreciated.
Yes, version 10.1, I'm using the tool because the table is the attribute table of a shapefile with x and y fields, and the GUI doesn't give you the option of using an existing layer. I can't throw the data up here, but I've tried it with four different feature classes and I get the same result, two shape fields, so it should be reproducable with any data, assuming it's not something related to my particular installation.
There are other different but probably related problems with the tool, for example from a different Excel table, I have no problem using the GUI to display XY data, but if I use the tool, I get a 000212 error, using the exact same fields and table.
Ok, not problem solved, but result achieved, the features of the event layer copy properly using the Copy Features tool, as opposed to the export GUI, which is the way I was doing it. I thought I had tried Copy Features before, but apparently not. So I can get to where I want, although unless I'm missing something, it's still a possible bug in the export GUI. The export GUI doesn't like the two shape fields, whereas the Copy Features tool apparently doesn't care. Thanks - Jeff
Am I correct in understanding that you are feeding a shape file .dbf table into MakeXYEventLayer? I imagine that Arc would indeed find that baffling, I know I do.
The "GUI doesn't give you the option of using an existing layer" because it is not expecting a feature table, but instead a table with coordinates but no features. It is carrying the existing shape field forward, and adding a shape field, and getting balled up over the two.
Try copying the .dbf (CopyRows) to a new table and dropping the shape field (DeleteField) before you feed it to MakeXYEventLayer.
editorial comment -> Of course, the fellow below is correct; making a non-spatial table drops the spatial field automatically. The point is that one should not be feeding points into a point-making tool.
I appreciate the comments and the alternatives to the one I came up with, but on the other hand, if the tool (not the GUI) was really intended not to work with an AT, then it shouldn't be inviting users to input one. In the GUI, it will not let you select a layer as input, whereas the tool will. The clear implication (to me, anyway) is that the tool, unlike the GUI, is designed work with either a standalone or an AT. And the fact that it runs, albeit errantly, rather than kick you out with an input error, is further support for that.
This is already logged as a bug, NIM075822. Unfortunately this is a known limitation in the software. The recommended workarounds have already been discussed in this thread, use Copy Features or FC2FC to create a new feature class from the xy event layer.