Hi Linda,

No.  I've mentioned only a few tables.  They might look something like
this:

[tblUser]
UserKey  (AutoNumber primary key)
UserFirstName
UserLastName
TypeKey (Long Integer foreign key)

[tblType]
TypeKey (AutoNumber primary key)
TypeName

[tblRate]
RateKey (AutoNumber primary key)
UserKey (Long Integer foreign key)
TypeKey (Long Integer foreign key)
RateYear
RateAmount

The tblUser table contains a record for each User.
The tblType table contains one record for each Type (you mentioned that
there are about 8 of them).
The tblRate table contains one record for each *combination* of User,
Type and Year.  For example, User A for LIAB in 2001 is in one record,
while User B for PROP in 2002 is in another record.

Also, this design would allow you to track rates for multiple types of
coverage for the same User - for example, a User may have both LIAB and
PROP, each in multiple years.

This is a relatively complex design to code in forms and reports.  Do
you know a more experienced developer that can help you out?

You won't have 125 Access tables, no. But do you now have separate "rate
cards" for each of your 125 users? Do you want to be able to set the
rate for each PrimaryType for each Year for each User quite
independently of the rate for every other User? If so, 125 Users times 8
PrimaryTypes means you have to store 1000 separate rates for each Year.

Looking things up based on three fields in a table containing thousands
or tens of thousands of records is absolutely no problem for Access. The
table would be like this:

tblRates
 User - foreign key into Users table
 Year
 PrimaryType
 Rate
   (Primary key of tblRates contains the 3 fields
    User, Year and PrimaryType).

But it seems unlikely that you really need to have a separate rate
structure for every user. In most situations with this many users there
would be some sort of categorisation of users and the rates would depend
on the category the user was placed in. So there might be a
tblCategories with categories such as
 Senior Partner
 Partner
 Junior Partner
 Senior Consultant
 Consultant
 Junior Consultant
 Research Consultant
 Junior Research Consultant
 Office Cat
and

tblUsersCategories
 User - foreign key into Users table
 Category - foreign key into tblCategories

and then tblRates would be
 Category - FK into tblCategories
 Year
 PrimaryType
 Rate

and you would use a query joining tblRates and tblUsersCategories to
retrieve the rate for a particular User, PrimaryType and Year.

Does this make things any clearer? (Another possibility is that the
rates are based on formulas of some kind; if so it's usually best to
have Access store the underlying values and formula(s) and calculate
each actual rate "on the fly" whenever it's needed.)

[snip]

--
John Nurick [Microsoft Access MVP]

Please respond in the newgroup and not by email.