I have two seemingly related problems I need some help with:
1) I have a feature class of points that I joined to a table of data saved as an .xls file. The join works perfectly, however when I make the join permanent by exporting the newly joined layer the new layer has no features, zero entries in the table where it should have 143. I tried several methods of extracting the dynamically joined layer to a new permanent feature class, in the end the only thing that worked was using the copy features tool.
2) Using that now permanent copied points layer, I made a new join to a layer of polygons keeping only matching records. The new table has 7 entries out of 143 possible. Using the normal data>export... method to make the join permanent I get a new feature class but this time instead of 7 features (or none like above) I get 143 features.
Does this sounds familiar to anyone? Any idea why this is happening?
I'm assuming you are joining your xls layer to the points feature class (not the other way around). You could create dummy empty fields before the join (with same data types as the xls table fields) and then after the join, populate those fields based on the joined table fields. That way, the data will remain permanently in the points feature class, even after the join is removed.
Joining table to points, then using Data>Export Data... to make a permanent copy of the points layer. I've done this hundreds of times and is basically the primary method for making a join permanent in ArcGIS. I've encountered the empty export issue a few times here and there but not the problem I described 2) above. Either way this is generally a straightforward function that we use all the time in Arc. It may be here data that's causing the problem, but I can't think of why.
That is indeed the usual approach. I was simply offering another approach, since the first appeared to be giving mixed results.
I appreciate the help, my exasperation wasn't pointed at you. I'm frustrated with the software! For a workaround using the copy features tool seemed to work ok and requires less manual work than the method above but its good to have multiple solutions.
But I really need to understand the underlying issue and how to resolve it not just for this student but for future ones as well. I work with dozens of students a quarter here and rely heavily on this function to make permanent copies of their analysis results and table joins and I can't be resorting to workarounds for such a basic function all the time.
I assume you've checked for leading or trailing spaces in the field names? Is the data available to share?
Because of one "&" in all of my dataset, that was in .csv file contaminated the whole join. It was deceiving because it joined successfully, but on the export, all the new values were null. Once i removed the "&" in one of the values, the data exported correctly.
I'm with the perceptive Mr. Quinn.
You need to be very careful with .xls and .txt tables that they follows Microsoft Jet/.shp/.dbf file naming limitations: No tables or field names starting with a number, no spaces, no special characters (except "_"), short (10-chars). To avoid trouble, I try to follow these rules with all datasets. You can always be more creative with field aliases and layer names, but the datasets themselves should use "safe" names. If you do that, field names are also less likely to be garbled if the geoprocessing workflow goes through .shp or .dbf formats.
If you violate these rules, the tabular data may be read okay, but joins are not likely to work.
As for the Copy Features tool, I believe it's a it's a much more useful method than data/export, since when you want to do it again (say after you change the underlying data), you don't need to go wandering through the interface, you can instead pull the Copy Features out of Geoprocessing results and re-run it. The Copy Features tool also is guaranteed to honor the specified environment settings for Current Workspace and Qualified Field Names.