Re: parsing records returned

I would suggest that the initial design of the address table missed a few requirements.

By "Address", I presume that you mean the portion of a mailing or delivery address between the recipient's name and the town name, state or province, postal code, and country if appropriate.

The elements of this part of the address, off the top of my head, are:

House number
Fraction
Pre-directional
Street name
Street type
Post-directional (e.g. Eye Street NW in the District Of Columbia) Unit type (e.g. Apartment)
Unit designator

...and that's all I can think of at the moment. And I've overlooked things like Mail Stop, Floor, and other identifiers that typically are included as a second line of an address. And then there are rural routes...

If your organization is serious about mailing, I would suggest that it should invest in serious address standardization software, e.g. Group 1. A one-line address has limitations for anything but the simplest uses.

One element of the original question - even or odd addresses - makes me suspect that someone is trying to do a delivery route application, or something like that. This is a further level of complexity.

So...it's time for a redesign of the table, IMHO, from the limited information presented here. And I suspect that this is more than a re-factoring project - it sounds like this application has black holes, not anti-patterns.

Good luck

Hank Murphy
speaking only for myself Received on Sun Sep 10 2006 - 22:06:15 CDT