topic Re: Exporting After Join in Geoprocessing Questions

Exporting After Join

KevinLaughlin — Tue, 20 Jan 2015 18:52:57 GMT

This is frustrating because this is something I've done a thousand times before. However, I have a feature class called Parcels and I'm joining it to an assessment table based on a common field called parcel number. In ArcMap, it works fine. When I export the table, or export a subset selection, the table columns are all <null> in the exported FC. It does the same thing when I create a layer based off of a selection. It exports field names, but not the data in them.

I've recently just upgraded to 10.3, so I'm not sure if this is a bug therefrom, or I'm just missing something.

Re: Exporting After Join

SusanJones1 — Tue, 20 Jan 2015 19:07:35 GMT

Hi Kevin

Please check the data type of the joining field in both the destination and source. It's possible that there is a difference - joining double with integer data types has done this for me in the past.

It's possible that one of the data input sources has changed.

Susan

Re: Exporting After Join

KevinLaughlin — Tue, 20 Jan 2015 19:45:29 GMT

The data sources are both strings.

Re: Exporting After Join

SusanJones1 — Tue, 20 Jan 2015 21:51:59 GMT

Hi Kevin

Are these fields are both less than 100 characters?

Are both these fields indexed?

Susan

Re: Exporting After Join

KevinLaughlin — Wed, 21 Jan 2015 14:43:01 GMT

They are not indexed and they're fields that were in existence prior to my use of them, so I'll have to double check on their length.

The feature class is a general parcel feature class, it has owner name and a parcel ID number. The table is one that I had to convert from a text file (that was the format in which I downloaded it). Whether I have imported it into Excel, Access, or a Geodatabase it has acted similarly.

Re: Exporting After Join

KevinLaughlin — Wed, 21 Jan 2015 14:46:04 GMT

The length of the feature class is set to 20. The length in the table is 255.

I imported the table from various formats, so could that field length be causing the issue?

Re: Exporting After Join

KevinLaughlin — Wed, 21 Jan 2015 14:48:24 GMT

I had to leave the issue and I'm just now coming back to it.

The fields are similar in type (string), are not indexed, and have different 'precisisons' (I don't think that's a word).

As I mentioned in a response above, the table was downloaded as a text file and I've used different methods (Excel, Access, into the Geodatabase itself) to import it into ArcMap getting similar results each time.

Re: Exporting After Join

KevinLaughlin — Wed, 21 Jan 2015 15:33:24 GMT

I meant field length. My bad.

I tried the join field tool and it gave me a similar result.

We don't have an option of an earlier 10.x machine. We're a small shop (two users) and we just upgraded everyone to 10.3.

A thousand may have been an exaggeration, but I would say I've done it quite a bit. When I was involved in the County I work for's parcel publication process this is how we published our parcels on a monthly basis - joined based off of parcel ID, and exported the join to get the final product. I do not remember it being this difficult before.

Tech support is an option, I just started here to see if 1) Anyone else had had this problem or 2) Maybe I could avoid tech support.

Thanks,

Kevin

Re: Exporting After Join

KevinLaughlin — Wed, 21 Jan 2015 16:40:43 GMT

I tried to run it with the join tool. It threw and error saying the Assessment Table lacked OIDs (as it was a conversion from a text file, this isn't out of left field). So I was able to export the table to a table that had and OID field. I then attempted to perform the join in ArcMap the usual way (right-click --> join, etc) and it works in ArcMap. I then exported the file and had the same issue, the newly joined data shows up a <null> values in the exported copy. The fields are there, but the data is not.

After this, I attempted to use the Join Field tool again. This time it threw a '999999' Error which means there's an error but the code can't tell me what's happening.

I'm going to try another office to see if they have similar issues (there is one that hasn't upgraded to 10.3 as of yet). If they can perform the join-export than I'm going to lean toward an upgrade issue. But, I'm still eliminating causes at this point.

Re: Exporting After Join

SusanJones — Wed, 21 Jan 2015 19:08:32 GMT

Hi Kevin

255 text length is a default when features have been imported from non ArcGIS Formats like excel.

It's possible there are trailing spaces which is not being matched to the feature class.

Perhaps try trimming the field on both sides

Problem sounds like it is on the Table side.

Susan

Re: Exporting After Join

SusanJones — Wed, 21 Jan 2015 19:11:02 GMT

Hi Kevin

sounds like the source is not a Geodatabase Table or recognised format.

It might be easiest if you import the table into a file geodatabase. The objectids will be added automatically.

Susan

Re: Exporting After Join

KevinLaughlin — Wed, 21 Jan 2015 20:24:10 GMT

Susan Jones‌

I took your advice and it worked. I was going to try one last thing before I went down the hall to try it in another office that hadn't updated from 10.2.

I imported the table into a file geodatabase. Performed the join with the imported table, and exported it and it worked properly.

Thanks,

Kevin

Re: Exporting After Join

KevinLaughlin — Wed, 21 Jan 2015 20:33:28 GMT

Kinda/sorta. I created an empty table and copied the original to it, which apparently wasn't the same thing.

This time, I simply created and empty file geodatabase and imported the original table (without OIDs) and it worked.

I'm confused myself.

Re: Exporting After Join

KimOllivier — Thu, 30 Apr 2015 21:37:27 GMT

What a wonderful insight to this problem that has bugged me for years. I avoid all exported joins because of the nulls, and I could never work out why. All I now have to do is check for the existence of a FID! My workaround is to create a python dictionary and run a cursor which is actually faster.

Might I also suggest SCHEMA.INI on your text files before you import them with TabletoTable? This is a standard Microsoft function that is used by ArcGIS to add a correct database schema to a CSV or TXT file. This avoids the dreaded 255 char wide fields, and properly defines integers instead of floats. All this will make joins more successful when it is finally in a geodatabase with a proper ObjectID.

Re: Exporting After Join

SusanJones — Fri, 01 May 2015 00:05:32 GMT

Agreed Kim Ollivier The da (data access) module for arcpy has been revolutionary for Geoprocessing at in ArcGIS.

Rows are treated as tuples with these new cursors. Geoprocessing flies.