I sure will, but I will not have any access to the data until Monday. I will then. Thanks for looking at it John!
>Tracy, I *think* I solved your problem in pure code without need for lookup tables, but can you send me a lot more addresses as a text file to
jskoziol4@comcast.net as I'd like to test some more to be sure.
>
>>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.
.·*´¨)
.·`TCH
(..·*
010000110101001101101000011000010111001001110000010011110111001001000010011101010111001101110100
"When the debate is lost, slander becomes the tool of the loser." - Socrates
Vita contingit, Vive cum eo. (Life Happens, Live With it.)
"Life is not measured by the number of breaths we take, but by the moments that take our breath away." -- author unknown
"De omnibus dubitandum"