I am creating a database for an archival collection with a 3-tier Table
structure in which any donor might donate multiple discrete Collections,
each containing multiple items.:

Donors > Collections > Items

In many situations I need to distinguish between Donors who are
Individuals and Donors who are Organizations, so I have a pair of radio
buttons on the Donor layout requiring the DonorEntity to be one or the
other.

I¹m uncertain, though, how best to structure the main main ŒDonor¹ field
itself because individual names and organization names have different
structures and behaviors.

For instance, for a name, I would be inclined to provide first, middle,
last names, while an organization would be a single slot. I suppose I
could treat individual names as though they were Company names in a
single field here, and add extra fields breaking down the name into
three parts for other uses . . . Or I should I have a Company-as-Donor
field and three Individual-as-Donor fields that I could concatenate for
various textual needs and make use of the Radio button info to draw
upon the appropriate fields in various instances? This approach, it
seems, might lead to creating a lot of scenarios where I create two very
similar layouts to cater to the two values.

For instance, in an ³Add a Collection² layout -- in the Donor foreign
key field linking the record to the primary keyfield ŒDonorID¹ in the
Donors table, I would like to use the ³Also display values from a second
field² so that the user doesn¹t have to consult an ID# list but if I
have two possible fields depending on the DonorEntity, I can¹t figure
out how to have it display the all possible values (I envisioned some
sort of ³If² calculation but it won¹t lt me use a calculated field as
the second displayfield because it can¹t be indexed).

So, can anyone offer some guidance or suggestions about managing this
Individual/Organization conndrum? I think this must be something that
comes up in lots of projects, and beyond this particular Keyfield
example, I¹m thinking that the approach I select here is going to have a
lot of consequences as I develop the database, so I want to be aware of
the likely implications and make the right choice from the get-go.

Thanks.
Albert

In article <asteg-02CCEE.11083127052007 (AT) news (DOT) west.earthlink.net>,
Albert <asteg (AT) mindspring (DOT) com> wrote:

Some ideas from my experience:

I set up the name fields on the basis of indivduals: NameTitle,
NameFirst, NameLast, NameSuffix.

When it is a company or organization I enter the name in the NameLast
field and leave the other name fields blank.

It is a good idea to have a separate field that identifies the entity as
an individual or organization, as you mentioned. You could have several
different values for this filed. Use of a value list helps here.

It is useful to make some calculation fields that concatenate the name
fields in various way, for example:

NameLastTitleFirstSuffix = Trim(NameLast & If(Not IsEmpty(NameFirst);",
"& NameTitle &" "& NameFirst &" "& NameSuffix:;""))

Then, when you set up the dynamic value list to pick a name from the
list, you use the concatenated calc field as the second field. (This
only works if all the fields used in the concatenation belong to the
same table as the primary key field you are using as the first field in
the value list)

Variants and refinements are possible.

Alternatively, you could use portals to create the related records, and
the relationships would be set up automatically. Set up the
relationships to allow creation of Collections from Donors, and to allow
creation of Items from Collections. Then put a portal to Collections in
a layout of the Donors table, and create new Collections records
directly in that portal. Put a portal to Items in the Collection layout,
to create the Items in that portal.

--
For email, change <fake> to <earthlink>
Bill Collins

In article
<bbcollins-6CD82C.14160427052007 (AT) customer-201-125-217-207 (DOT) uninet.net.mx>,
Bill <bbcollins (AT) fake (DOT) net> wrote:


This may not be a good idea since it means you can't put in a contact
name for the organisation. You might be better off adding a proper
Organisation Name field and leaving this one blank for individuals.

Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)

In article <280520070855008228%helpful_harry (AT) nom (DOT) de.plume.com>,
Helpful Harry <helpful_harry (AT) nom (DOT) de.plume.com> wrote:

I understand Helpful Harry's comment, and I think his advice generally
is excellent. There are various ways of doing this.

I prefer my approach, as it makes the NameLast field the single most
significant field for identifying the donor. I would turn Harry's
suggestion around and make a separate field to identify the primary
contact person in the case of an organization.

You can choose your approach on the basis of what makes the most sense
for your needs.

--
For email, change <fake> to <earthlink>
Bill Collins

In article
<bbcollins-00CBE7.21344827052007 (AT) customer-201-125-217-207 (DOT) uninet.net.mx>

Thanks for the suggestions.

I'm thinking if I tried your suggestion, I could have a second occurence
of the 'Last name' field on the layout with a label indicating
'Organization' -- then the user wouldn't have to remember that the org
goes in the last name slot, right?

Is there a command that would deny access to certain fields if a value
is entered in the 'Individual / Orga" field? I'm thinkign it might ben
ice if the User clicks a radio button for 'Organization,' the fields
with the first name, etc. darken and deny entry..?

Also, Bill -- thanks for the name concatenation pointer -- do you not
use a field for middle name?

I'm defintiely using a portal for the COllection > Items generation, and
am weighing whther or not to do the same for Donors > COllection. There
was some reaosn yesterday why I was considering this different approach.

best,
albert

In article <asteg-348AB0.07560428052007 (AT) news (DOT) west.earthlink.net>,
Albert <asteg (AT) mindspring (DOT) com> wrote:

Look af field validation for an answer to your first question above. You
can do validation based on calculation, which would not allow entry in
the field depending on the outcome of the calculation.

I don't use a separate field for middle name. I simply include middle
name with the first name. That is a matter of preference. You might
prefer to have a middle name field.

--
For email, change <fake> to <earthlink>
Bill Collins

THanks again.
.. . . but Eureka! I just discovered an ideally simple solutiion to my
original problem! Instead of thinking of the Top-level records being
Donors, I can conceive of it as Donations -- and create a single field
for "Name of Donation" as in:

Priscilla Pinhurst Bequest
Johnny Appleganger Purchase
EMF Electronics Salvage Lot
Anthology Archive Deposit - 2007

Then the needful names and organization fields are simply 'contact'
info. This also has the virtue of allowing more than one Donation record
in the event of successive donations from a single entity (or the option
of simply continuing to add to an earlier donation instead). It also
maintains a parallel noun structure grammatically:

Donations > Collections > Films

It came to me over a grilled cheese sandwich!

Albert

Never underestimate the power of the Grilled Cheese!!!
http://www.unexplained-mysteries.com...howtopic=79607

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Reality is the leading cause of stress...
....amongst those in touch with it.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
WinXP Pro 64Bit / FMP Adv 8.5v2
VoicesInMyHead
a.k.a. The Voices
No, we're not... Yes, we are...
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-