There was an error trying to process this table.

[JustinTomei]

I have a dataset of about 32000 addresses I have been trying to geocode. Time after time I keep getting the same error message, the one in the title of this thread. I have changed names of columns, tried making it a dbf, tried removing everything but the address information, splitting the data in half to make it smaller. Regardless of what I do i get anywhere from 1%-5% done and I get the error.

Any ideas?

Thanks.

[ObiOfoegbu]

I get the same error. I opened an old file I had worked on before. Tried geocoding new table with World Geocoding Service and same error. I tried geocoding a table I had previously geocoded earlier this year and same error. So clearly something is wrong with the application because it had geocoded that data previously.

It doesn't even get past 0% for me before giving me the error. Any pointers??

[StevenGraf1]

The World Geocode Service takes an ArcGIS Online subscription account.  It will let you log in using your global account but won't let you geocode.  It will sit at 0%.  Could this be the issue?

[ObiOfoegbu]

The World Geocode Service takes an ArcGIS Online subscription account.  It will let you log in using your global account but won't let you geocode.  It will sit at 0%.  Could this be the issue?

Yup it was. Had to call tech support and use a local locator on my hard drive.

Probably be best for Esri to have that as default with option of online version just as they have the MGRS as well.

Thanks for your help.

[ShaningYu]

I got the same message.  The error is really hard to detect.  I used the procedure below to go through my geocoding process:
1) Break the table in several parts (by definition-query).
2) Geocode against the table.
3) If find unmatched, check both the source table and the data table, and make sure the data in the data table match the key field values.
4) After geocoding all of the data, merge the geocoding results as one file.

[alex_friant]

I found this page searching for the same error:

"There was an error trying to process this table"

I didn't see my resolution here, so I thought I'd share it:

If the address input table contains either one of the following field names, Geocoding the table will fail:

• SHAPE_STArea__
• SHAPE_STLength__

Those are 2 underscore ('_' + '_') characters at the end of the field name. It has to be 2 underscores; 1 is no problem. It's a bug I'm going to document with Esri Support for our case.

I got those fields because I was trying to create a small stand-alone test table based off a subset of feature attributes by exporting them from a feature attribute table. It took forever to figure out why the bug was occuring with perfect data, and I'm sure it's not a very common occurence, but if you have either one of those fields in your input CSV or stand-alone geodatabase table, Geocoding your table will fail.

[alex_friant]

Just discovered that if you use these exact names in your input table, geocoding fails as well:

• SHAPE_STArea
• SHAPE_STLength

The reason this is causing geocoding to fail is because the output is a POINT feature class, and when ArcGIS is attempting to generate a new feature class, it gets rejected because POINT feature classes aren't allowed to have those reserved field names. It makes sense, but it seems like the geocoding module should check for those things, like reserved field names, when you provide the input table and so not allow it to be used as an input table (maybe a red circle exclamation point thing ArcGIS GP tools are so fond of using when they anticipate an error with the input provided). Or at the very least, specifically tell the user in the error window that the input table contained field names that aren't allowed in a point feature class, instead of it being some mysterious issue (as this thread can attest to).

[Anonymous User]

As Alex stated Geocoding has reserved field names.  I just discovered this too when using a feature class that has GlobalIDs field.  They only primary key allowed is the ObjectID field.  Your feature class can't have any other primary keys like the GUID would be. 

As Alex stated you also can't have reserved shape field names like Shape_STArea and Shape_STLength.  I only figured out the issue when I chose to output a shapefile instead of a feature class or enterprise feature class.  I'd recommend using the shapefile output since it seems like the error handling is a little better. 

I've never had a problem with Nulls in my datasets. I have individuals geocoding really large datasets against it (911 Calls for service) which amount to over 500,000 calls sometimes when they run their yearly reports. I am geocoding against a public facing geocoding service that we host in house. I rebuild it nightly using ArcPy using the following logic:

1. Stop the geocoding service
2. Rebuild each individual locator inside my published composite locatore
3. Start the geocoding service 

I never have any problems with this methodology and I've had it in place for about a year now.  Every now and then the rebuild will fail and I'll have to recreate them, but that hasn't happened since we've moved to the 10.4.1 environment. 

[ShanaBritt]

Brandon, we are looking to resolve the problem (NIM076288) with Global IDs in a future release of ArcGIS Pro and ArcMap, which will be beneficial to those using feature service tables or data that requires Global IDs for use in other applications and workflows throughout the ArcGIS Platform. https://support.esri.com/en/bugs/nimbus/TklNMDc2Mjg4 .

[Anonymous User]

That sounds fantastic Shana!  If possible we'd love a list of reserved field names too when Geocoding.  It seems like the error handling is there when it comes to exporting to shapefiles, but when exporting to an enterprise database the error handling isn't there. 

[GregRouse]

One other *weird* thing to check for......when I received a spreadsheet from another office for a geocoding project I was working on, some of the cells were "locked". (I'm not sure why)  Anyway, after a couple hours and much frustration, I stumbled onto the locked cells in Excel.  Unlocked the cells and worked like a charm.