Your proposed table structure suggests that tblRoster is a junction table
between tblTeam and tblMember

Your analysis is incorrect! Read my first post and the note for TblRoster.
Read my last post for the reason to have TblYear. RosterID represents a
specific member on a specific team for a specific year.

Steve


"BruceM via AccessMonster.com" u54429@uwe wrote in message
news:a3c7d520d1842@uwe...
I don't know if you are responding to me or to the OP, but since you
responded directly to my posting I assume it is me.

Perhaps you didn't get that I was trying to get the OP to implement a
small
piece of the design for starters. I know that other forms are needed.
That
should be clear from my posting where I mentioned the next step.

I question the value of a one-field top-level table (Year). I would argue
for a Year or SeasonStart field or some such thing in the Roster table.
Your
proposed table structure suggests that tblRoster is a junction table
between
tblTeam and tblMember, which makes sense since a team rather than a year
has
a roster. It's hard to see how a table that links to tblYear and tblTeam
is
going to help anything. It's simple enough to restrict records to a
single
year.


Steve wrote:
One of the data entry forms needed is to be able to enter TblRoster data
for
a given year. This is done with a form/subform. The main form is based on
TblYear and the subform is based on TblRoster. A lot is accomplished doing
it this way. It removes the possibility of incorrectly entering HockeyYear
in TblRoster.
It gives you an efficient search for a selected year. It gives you a clean
way to delete all roster data for a selected year. Plus many other
benefits.

Steve


An ID field that is used as a linking field is like an EmployeeID
number.
You can move, change your name, go into a different departemnt, or
[quoted text clipped - 13 lines]
table, and then only to store the four-digit year without a separate ID
field)

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