Exporting a joined layer results in empty dataset, need help.

[DavidMedeiros]

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?

Dave

[MathieuCain]

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?

Dave

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.

[DavidMedeiros]

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.

[MathieuCain]

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.

[DavidMedeiros]

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.

[MathieuCain]

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.

Likely a silly question, but you're exporting "All Features" as opposed to "All Features In View Extent" I presume.

[JonathanQuinn]

I assume you've checked for leading or trailing spaces in the field names?  Is the data available to share?

[curtvprice]

I assume you've checked for leading or trailing spaces in the field names?  Is the data available to share?

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.

[robstrange]

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. 

[DavidMedeiros]

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.

Just wanted to get back to this after having reviewed the input table. As far as I can see, no special characters, no numbers first, no spaces etc. I always follow the same rules but hadn't specifically checked this students table so wasn't sure. It may just be a bad table creation process leading to some underlying issue with the table itself. Although I can't see how it would successfully join to a layer but not export.

As for exporting dynamic joins and selections, I typically use the data>export method because its right there on the layer. For the researches and academics I work with the contextual right click tools are often easier to find than toolbox tools and it fits their one-off work processes better I think. That said, the Copy Features tool obviously works better with iffy table joins so maybe I need to switch to that tool right away.