redo my design

[shumate62]

I'm trying to build a database with minimal working knowledge of Access so
even though I've been through the tutorial it seems way more complicated then
what I need. I have a list of people's name for an annual event and basically
need an address book for mailing labels but I need to be able to sort them
for about 10 different fields (author, speaker, speaker's guest, media,) but
some people belong to more than one group so if I do a print out of labels I
want to be able to select to just print 'media and speakers' etc. was this
still supposed to be two tables joined together?

 

[John W. Vinson]

I'm trying to build a database with minimal working knowledge of Access so
even though I've been through the tutorial it seems way more complicated then
what I need. I have a list of people's name for an annual event and basically
need an address book for mailing labels but I need to be able to sort them
for about 10 different fields (author, speaker, speaker's guest, media,) but
some people belong to more than one group so if I do a print out of labels I
want to be able to select to just print 'media and speakers' etc. was this
still supposed to be two tables joined together?

No... you need three tables, not two.

Each person may play several roles (speaker, author, media); each role may be
filled by several people. You should consider a table of people (PersonID,
lastname, firstname, address, email, etc.); a table of Roles (about ten rows
in it at the moment); and a table of PeoplesRoles, fields PersonID and Role,
with one record for each role that a person plays.

You can fill this in easily by having a Form for people with a subform based
on the PeoplesRoles table; use the PersonID as the master/child link field and
a combo box based on Roles to select the role.

Your mailing list would be based on a query joining all three tables, with a
criterion on the role. You can use "OR" logic on the criteria by selecting
"Speaker" on the first criteria line in the query grid, "Media" in the second
and so on, to get a label printed out whichever role a person plays. Use the
"UNIQUE VALUES" property of the query to print only one label per person.

 

[Steve]

You can do this with three tables ....
TblPerson
PersonID
<name and address fields>

TblGroup
GroupID
Group (author, speaker, speaker's guest, media, etc)

TblPersonGroup
PersonGroupID
GroupID
PersonID

TblPersonGroup gives you a list of persons in each group.

To print your labels, create a query that includes TblPerson and
TblPersonGroup. Include the name and address fields from TblPerson and
GroupID from TblPersonGroup. Set the recordsource for the labels to this
query. You can set the criteria of GroupID for the Group or groups you want
to print.

Steve
(e-mail address removed)

 

[shumate62]

So, I made the three tables as suggested, tblPerson, Tbl PersonGroup,
TblGroup and then tried to create the relationship for them but it's stuck on
only having a one to many relationship, which of course it isn't it's a many
to many (there are multiple authors, and people belong to more than one
group) did I do something wrong in the formatting of the tables that blocked
it from being a many to many?

 

[Duane Hookom]

Why not take a couple seconds to explain which tables/fields you attempted
to create the relationships on? The person and group tables should each be
joined one-to-many to the Person Group table.

I hope the space in "Tbl PersonGroup" is just a typo. Avoid all spaces in
object names.

 

[John W. Vinson]

So, I made the three tables as suggested, tblPerson, Tbl PersonGroup,
TblGroup and then tried to create the relationship for them but it's stuck on
only having a one to many relationship, which of course it isn't it's a many
to many (there are multiple authors, and people belong to more than one
group) did I do something wrong in the formatting of the tables that blocked
it from being a many to many?

There IS NO SUCH THING as a many to many relationship in the table relations
window. The only relationships you can see in the window are indeterminate,
one to one, one to many; the first is useless and the second is legitimate but
pretty rare.

A many to many relationship *consists* of two one to many relationships.

Each tblPerson record is related to many tblPersonGroup records - a one to
many relationship. Each tblGroup record is related to many tblPersonGroup
records - another one to many. tblPerson is only related to tblGroup *by way
of these two one to many relationships* - it's indirect; each record in
tblPersonGroup encodes the information that one particular record in tblPerson
is related to one particular record in tblGroup. If there are many connections
between the two tables, each such connection is stored in a different record
in tblPersonGroup.