[AccessD] International Addresses

[Rocky Smolin]

It's also easy then to give them a report writer - essentially a list of
filters on each field - and they select the field by the label they've
given it. So it makes sense to them from the outside. You can also five
them a sorting option on 1 or 2 or 3 of the fields selected from combo
boxes whose data is a Value List of the labels.

Then they won't be pestering you for a query for every unique way they want
to slice and dice the data.

r

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

> Thanks Rocky,
>
> I like your suggestion for having them label the fields.
>
> Regards
>
> David Emerson
> Dalyn Software Ltd
> Wellington, New Zealand
>
>
>
> -----Original Message-----
> From: AccessD <accessd-bounces+newsgrps=dalyn.co.nz at databaseadvisors.com>
> On
> Behalf Of Rocky Smolin
> Sent: Friday, 12 November 2021 10:34 am
> To: Access Developers discussion and problem solving
> <accessd at databaseadvisors.com>
> Subject: Re: [AccessD] International Addresses
>
> 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
>