You're taking the wrong approach. Write an e-mail to the USPS and tell them to start using lat/long for addresses. Then they could just deliver to that spot on the globe and if there's no mailbox there, then, darn it all, you're just not gettin' your mail. Seems like they could implement this in a week or two!

>Actually, I can pick out the street UNLESS the street name has two words in it which is common around here. Then it is basically impossible. Also rules would have to be put into place such as you cannot have a an st_suffix without an st_type or no apt_room without an st_suffix, etc. Otherwise it is basically impossible to determine which value belongs to which field after the street. We do have lookup tables but I was trying to work something out for those addresses that are not in the lookup tables...Just can't be done reliably...
>
>
>
>>>>But, if you include the city, state and zip on the next line, ie. [1312 S Caom St E Suite A10] + CHR(13) + [City, State Zip], it handles it just fine.
>>>>
>>>>The one thing it doesn't seem to handle very well is separating out PO Boxes from street addresses.
>>>>
>>>>Regards,
>>>
>>>It doesn't break street to pieces as Tracy requires. It's not an easy task without supporting lookup tables.
>>>
>>>Try it with [1312 S Caom St E Suite A10] + CHR(13) + [Kew Gardens, NY, 11415]
>>
>>AFAIK Andrew had another article about parsing addresses. Anyway, Outlook doesn't seem to parse street to its pieces.