Bob

My point is, I believe, to NOT use "type" or repeating values (i.e.,
data/row values from one table) as the field names of another.

If you are saying that you have person, event, and person-at-event data, use
three tables. Isn't this a little like a hotel reservation, where you have
person, room and person-reserving-room? That third table only contains the
personID, the eventID, and any info specific to person-at-event. Note that
this would NOT include date-of-event, as that is a characteristic of the
event. Note that person address or phone number is NOT part of
person-at-event, as these are characteristics of a person.

But with a table structure like this, you can retrieve the address of a
person at a specific event by joining the tables in a query.

And you can use the "unmatched" query wizard to help you get a list of folks
who were NOT at a particular event.

Also note - you would NOT need to store a person_NOT-at-event record -- this
can be derived from the unmatched query mentioned above.

--
Good luck

Jeff Boyce
Access MVP