Hi Mike

To me this sounds suspiciously like you have 10 fields in your meetings
table for the 10 possible attendees.  Is this right?  If so then this is not
good table design.  What happens if you get 11 people attending a meeting?
How can you easily list what meetings were attended by John Smith or Mary
Brown? How can you easily count the number of attendees at each meeting?

In actual fact, you have a many-to-many relationship between meetings and
people - a meeting can be attended by many people, and a person can attend
many meetings.  The ONLY way to store this data reliably is using a third
table, called a "junction table". Let's call it "MeetingAttendance"

Your MeetingAttendance table needs two fields, one to contain the primary
key value of the meeting being attended (let's call this field "MeetingFK")
and one for the PK value of the person attending ("PersonFK").  You must
then set up a one-to-many relationship between the PK field of your Meetings
table and the foreign key field (MeetingFK) in MeetingAttendance.  The same
applies between your People table and MeetingAttendance.

You might also like to add some further fields to your junction table - for
example, the Role (chair, secretary, etc) that the attendee performed at the
meeting.

Now, you add and remove attendees at the meeting by creating or deleting
records from your junction table.  This can be done with a subform (the
traditional method) or with a listbox, a combo box, a couple of command
buttons and some code.

As far as setting up the default attendees, I suggest you have another table
of "MeetingTypes" (Finance committee, Social club, etc) and another junction
table of DefaultAttendees, with MeetingTypeFK, PersonFK and Role.

When you add a new meeting record and specify its MeetingType, it is then an
easy matter to run an append query to add to the MeetingAttendance table one
record for each record in DefaultAttendees that corresponds to the selected
MeetingType.