Is US Dual Ranges broken in 10.0 sp4 if you map ZIP? very slow w/o?

[HarryBowman]

Case 1:
Streets are in file geodatabase and mapped addresses, type, street name, etc.
Mapped L/R city
Mapped L/R State
Did not map L/R Zip
Results: very slow

Case  2:
Streets are in file geodatabase and mapped addresses, type, street name, etc.
Mapped L/R city
Mapped L/R State
Mappe L/R Zip 'CORRECTION: DID MAP L/R Zip Initial post had this incorrect'
Results: 0 candidates

Am I missing something? The L/R Zip is Canadian FSA, example: H3X

[JoeBorgione]

Case 1:
Streets are in file geodatabase and mapped addresses, type, street name, etc.
Mapped L/R city
Mapped L/R State
Did not map L/R Zip
Results: very slow

Case  2:
Streets are in file geodatabase and mapped addresses, type, street name, etc.
Mapped L/R city
Mapped L/R State
Did not map L/R Zip
Results: 0 candidates

Am I missing something?

This might be a similar situation to a problem I was having a few weeks ago.

It seems that the 10.x locators are a little more particular than we've seen in the past; you may need to map your zip codes.

[HarryBowman]

Correction to initial post: In the second, zero candidate case, I did map the zips. They were Canadian FSAs, like H3X.

[HarryBowman]

Did an experiment. Instead of the real FSAs as Postal Code (ex: h3x) used a fake: 12345. Worked. OK....why?

[JoeBorgione]

Did an experiment. Instead of the real FSAs as Postal Code (ex: h3x) used a fake: 12345. Worked. OK....why?

Ohhhh.... Canandian data.... All bets are off!  No; just kidding...  Thats a really good question!