Geocoding Dual Range 10.1 No Zipcode to Geocode

[KaraRoberts]

I've seen a lot on the forum about a bug in ArcMap 10 (that was fixed with SP1) on dual range address locators and I might be having the same problem in 10.1  I set up a address locator using dual range, geocoded my points, and I have one location that is not matched.  From the "Interactive Rematch" dialog window I attempt to delete out the zip code then click on search but nothing happens.  I've tried puting <none> in the zip code text box, I've tried "NULL", and I've tried 00000 but I never get any candidates returned.  I think this is the same bug people were complaining about in 10 but I'm finding it in 10.1  How can I get this location matched without using the zip code?

[KaraRoberts]

I should also mention that my address locator has a null zip code for the street it should be using to place this point.

[LucasDanzinger]

I think you are running into the following bug which resurfaced at 10.1: NIM081790: When batch geocoding or locating addresses and instersections in the geocoding toolbar and Find tool, an address locator based on the Dual Range locator style does not return matches or candidates when city, state, or zip fields are not mapped.

Try this workaround:
1. In ArcCatalog or the Catalog window, right-click the address locator
2. Click Properties�?�
3. In the Geocoding Options section change 'Match with no zones' from �??no�?� to �??yes�?�

[DominickCisson]

I think you are running into the following bug which resurfaced at 10.1: NIM081790: When batch geocoding or locating addresses and instersections in the geocoding toolbar and Find tool, an address locator based on the Dual Range locator style does not return matches or candidates when city, state, or zip fields are not mapped.

Try this workaround:
1. In ArcCatalog or the Catalog window, right-click the address locator
2. Click Properties�?�
3. In the Geocoding Options section change 'Match with no zones' from �??no�?� to �??yes�?�

   Has this bug been fixed yet?  We are running 10.2.2 and still seeing the issue.  We have a problem because we run scripts to rebuild local locators on a regular basis, and the "Match with no zones" flag constantly gets switched back to "no" every time, breaking our address locators for all intents and purposes.  Is there a way to programatically set the environment, or set a reg key somewhere to make "yes" the default here?

[JoeBorgione]

Not sure if this will help you or not:

http://support.esri.com/en/bugs/nimbus/TklNMDgxNzkw

To permanently fix if you are not able to install 10.1sp1 use the following steps.

1. Open the USAddress.lot.xml file located in the c:\program files\arcgis\desktop10.1\locators folder in an XML or text editor.
2. Change the two occurrences of the following tag from false to true.

FROM
false

TO
true

[DominickCisson]

Not sure if this will help you or not:

http://support.esri.com/en/bugs/nimbus/TklNMDgxNzkw

Well, that sure looks like the fix, except that when it says to "Change the two occurrences of the following tag from false to true" there is no "following tag" actually given to change.  I assumed it might be the "supportsOptionalZone" property in the XML file, but that didn't seem to work.  Guess I can randomly start flipping property flags, re-creating locators, and repeating until something sticks, or bounce this back to ESRI and see if they'd like to fill in the blank on this bug.

[DominickCisson]

Well, that sure looks like the fix, except that when it says to "Change the two occurrences of the following tag from false to true" there is no "following tag" actually given to change.  I assumed it might be the "supportsOptionalZone" property in the XML file, but that didn't seem to work.  Guess I can randomly start flipping property flags, re-creating locators, and repeating until something sticks, or bounce this back to ESRI and see if they'd like to fill in the blank on this bug.

Actually it is the "supportsOptionalZone" tag that does the trick.  Just need to restart ArcCatalog (duh) to re-read the updated XML.

There's a better technical article that outlines the fix here, with the actual tag to update actually mentioned.

(http://support.esri.com/ru/knowledgebase/techarticles/detail/40678)