Fred,

Working! Simple is better.

I have decided that date is an entity. Four tables and a query.

SQL:
SELECT tblChurchDate.ChurchDate, tblFunction.Function, tblPeople.Name
FROM tblChurchDate INNER JOIN ((tblChurchDateFunctionPeople INNER JOIN
tblFunction ON tblChurchDateFunctionPeople.FunctionID = tblFunction.
FunctionID) INNER JOIN tblPeople ON tblChurchDateFunctionPeople.PeopleID =
tblPeople.PeopleID) ON tblChurchDate.ChurchDateFunctionID =
tblChurchDateFunctionPeople.ChurchDateID
ORDER BY tblChurchDate.ChurchDate, tblFunction.FunctionID, tblPeople.
PeopleID;

The reason I am doing this is to get the table structure and the SQL to
create a mySQL db for a website. I am just starting to learn how to do a
mySQL. Now I have to see how to get this to work on a web page.

Wish me luck.

Thank you Fred & Steve.
Scott


Fred wrote:
Scott,

I only briefly perused the subsequent exchange, but if you make a solid
decision on the entities being database and then a solid table structure
based on that, then I think you job will be much easier / more successful.

The first question is whether "dates" are an entity that needs databasing
vs. just an attribute of other entities.

If the answer is yes, the next question is whether or not your "date"
entity has other 1:1 attributes that you will be actively databasing. That
will make the difference between a true data table vs. a table that is just
there to populate dropdown lists.

Either way, I suspect that you will need to ditch a few of your tables and
your main 3 tables should be:

People

Functions

InstancesOfAPersonServingAFunctionOnAParticulerDa te (of course, shorten
that). This table will have FK's for People and Function and probalby just a
date field, but possible a FK for a dates table, if the latter is truly an
entity that needs databasing.

Well, there's my 2 cents.



Even if the answer is the former, then the next question is whether or not
you need to

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...esign/200912/1