X-no-Archive:yes
Zip codes are a good example. Regulated industries like insurers have a
vested interests in being able to mail you information in a reasonable
amount of time (passing the buck back to you). It may be enough for some
applications to simply ensure that the zip code is five, nine, or eleven
digits, whereas others need to ensure that the post office can deliver to
that zip code, or may even use the zip code as part of a rating algorithm.

While two letter state abbreviations are notoriously stable data and can be
validated in the interface, validating a zip code is a bit trickier. That
should assume a valid look up table (and probably a subscription to a
service that provides timely updates when the postal service adds new zip
codes or some nifty way to handle exceptions while supporting the business
needs to allow data entry and mail delivery to both succeed), and that is
probably going to have to be host-based, either in the application, or in
the DBMS which would then return an error to the application for the
application to deal with and present back to the user. I can conceive of no
case where this could be entirely handled in the interface. Then again, it
cannot be entirely handled by the application or the RDBMS alone.

That said, doesn't Image give us means to ensure that I cannot add a record
with a zip code that does not already exist in a lookup table? Hmmm...

Greg Stigers
http://www.cgiusa.com

-----Original Message-----
From: Tracy Pierce [mailto:[log in to unmask]]
Sent: Tuesday, March 20, 2001 12:22 PM
To: [log in to unmask]
Subject: Re: Image Data Types

some sort of switchable middleware might fill the bill.  When Image starts
getting bashed because it doesn't verify my zipcode extension as well as
Oracle, integration has gone a bit to far for my taste.

Tracy Pierce