Why does the attribute name fields change after performing an intersect?
I'm sure. It appears the new name is of a subset of the original name that was created after I geocoded the original file. I'm sure I just confused you there.
Synopsis: I geocoded some data, then called the layer "geocoded results" (attribute table not disturbed) then I performed the intersect. This is when the attribute field names changed automatically to "geocodi_XX (1-100)". The reason this is a problem for me...is because I am going to convert this file into an excel table and provide the data to a customer. This is a rather large dataset; encompassing over 5000 records and not a simple task of manually changing the names back. I think I may have to re-invent the wheel and perform the process all over. Thanks for your help.
Have you tried finding ways around this? Like using 'Select by Location' or 'Select by Attributes'?
I have not.
What type of output are you writing to? A shapefile? File Geodatabase Feature Class?
shape file
Uggh. The demise of modern civilization. Try it to a file geodatabase feature class and see what happens.
That's your problem right there. Shapefiles have limits on field name width, which are generally dealt with by making aliases in metadata and naming the columns to sequential names that don't conflict.
Do your analysis in FGDB then rename the columns on export to shapefile when you're done.
- V
or use far better naming conventions for shapefiles in the first place right Vince?
That's difficult, because there aren't any good naming conventions that merge source name and field with an underscore in ten characters. It's all part of why shapefiles should be avoided (naming limits, lack of wide strings, BLOBs, CLOBs, and numeric nulls, limited date representation, 2Gb file limit...)
- V
the files had the same field names, you can have this since you don't want to overwrite existing data, hence the field name change based upon a minimal intrusion name outcome