[AccessD] International Addresses

[Rocky Smolin]

Given how little view they're giving you on how the data will ultimately be
used, I'd go with the Address fields 1, 2, 3,etc. - would probably name
them internally as fldxxx1, fldxxx2, etc. so that if one field was not an
address datum - like a name, company, person, etc, it wouldn't confuse the
inheriting programmer with field names that all had 'address' in them.

And I'd go with 8 lines because I can see a six liner,  which means (if I
was designing it) I'd have two lines for expansion. Also, they may want to
use the extra line for telephone number, email, or other communications
purpose. And of course, easy to add another date field and corresponding
label for expansion.

Then, I would set up a labels table (I did this recently, to give the user
flexibility in defining the field from the UI POV, without having to come
back to me for each change) so that they could define their own captions
for each field's label.  The labels would be a back end table, of course.
This way, you give them maximum flexibility.  If they want to standardize
at some later date, all the data is there in separate fields for a
conversion program to crunch.

What are the +s and -s you see to this?

hth

r

On Thu, Nov 11, 2021 at 12:46 PM David Emerson <newsgrps at dalyn.co.nz> wrote:

> Hi Listers,
>
> I am writing a system that potentially could be used globally.  I am
> looking
> for guidance on how to handle storing address fields.  At this stage the
> data is just to record site addresses and probably (famous last words) will
> not be used for mailouts as most of the sites will be unattended.
>
> Should I just use a simple structure such as AddressLine1, AddressLine2,
> AddressLine3, Addressline4, AddressLine5 or is there a more elegant way of
> doing it?
>
> Regards
>
> David Emerson
> Dalyn Software Ltd
> Wellington, New Zealand
>
>
>
>
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> https://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>