The 2nd argument is used only if the first is null.
The way too easy solution sometimes flies right by me - thanks for going
easy on me.
Okay this is a good structure.
Thanks again - I'm a little defensive on the structure because it was the
only solution I thought I could use to handle the various relationships,
and
the client knows just enough about database design to be dangerously
critical
of me "making it more complex than it needs to be".
I prefer a Number field to specify the priorirty rather that a yes/no to
indicate if it is the primary one, because it means the records are
independent of each other, e.g. if the number 1 contact/address is out of
circulation temporarily or permanently, the second one gets returned by
your
function/subquery.
It usually involves a subquery to return the ID of the preferred, current
address. Alternatively write a VBA function that accepts the arguments
for
the client, and optionally address type and date (if you have a full
history
of addresses), and returns the string suited for the address panel
(OpenRecordset sorted as desired, and build string from first record.)
The home office "direct" Address I'm trying to incorporate is linked to
the
Contact through the tblCONTACTSMULTIPLE without being assigned to a
CompanyID. But for now, all of my queries draw a Contact's Address
through
the [PrimaryCompany] that is indicated, using the AddressID assigned to
the
Company in the bridge table; the AddressID field is blank in the
tblCONTACTSMULTIPLE for all ContactMultipleIDs with ContactIDs, except for
those with Addresses independent of any Company they are linked to. This
is
why right now the queries and reports only display the main Company
information until I can work through this linkage/priority issue to
display
the "direct" Address first, but If Null then display the main Company
Address.
I've thought about adding [DirectAddressLine1], [DirectCity], etc. fields
to
tblCONTACTSMULTIPLE which is where I have my direct [OfficePhone],
[OfficeFax] fields, rather than in tblADDRESS linked by AddressID but my
instincts tell me I'll have problems with that. Your Priority Number
field
idea is intriguing, but I have concerns about it because it means
populating
a couple thousand Contacts with a priority level I honestly have no clue
how
to assign (Owners, Presidents and GMs currently are typical
[PrimayContact],
[PrimaryCompany] Contacts; COO's, Sales Mgrs, EVPs, Attorneys, Vendor
Reps,
etc. have no priority that can be discerned for the purposes of my client,
but some of them have home "direct" addresses).
A problem I foresee is the structure of how I've built the links for
AddressID to ContactID through the [PrimaryCompany] AddressID for the 80%
who
belong to just one company and have no direct address concerns, and to
link
an AddressID directly to a ContactID (who may or may not be a
[PrimaryContact]) through a ContactsMultipleID involves another data entry
step to enter in the same address for the 97% of ContactIDs who will have
no
direct address was a method the client rejected.
Also, it's worth noting that in tblCONTACTSMULTIPLE, the 3% I'm concerned
with are the only Contact records that have a ContactsMultipleID,
ContactID
and AddressID assigned, with no CompanyID assigned. The 97% have
ContactsMultipleID, ContactID and CompanyID assigned, with no AddressID
assigned. And all Company records have ContactsMultipleID, CompanyID and
AddressID assigned, with no ContactID assigned. Can these distinctions be
used in creating a query that handles my dilemma?
Lastly, is there a streamlined way to change my Primary Contact/Company
field data type from Y/N to Numeric across all of the queries, forms and
reports I've already developed so that if I come to the conclusion that
your
Priority Numeric proposal is still the most feasible and I change the
field
type in the table I won't have to go to every query, form and report to
make
the corresponding changes. I don't have Object Dependencies or
AutoCorrect
enabled in this database - they corrupted a prior database I developed and
I
had to export everything to a new database. If not, I guess making those
manual data type changes falls under the less glamorous part of database
development.
Thanks again.