relationships have two sides; you must define both to determine what type of
relationship you're working with:

One client can have many invoices AND one invoice may belong to only one
client.
1:n (n represents an unknown value, it may be one, many, or none)
One client can have many payment plans AND one payment plan may be assigned
to many clients.
n:n
One invoice can have only one payment plan AND one payment plan may be
assigned to many invoices.
n:1 (though normally one-to-many relationships are expressed *from* the one
side *to* the many side, since that's how the relationship is actually set
up)
One client can have many classes AND One class can have many clients
n:n
One trainer can have many classes AND One class can have many trainers
n:n

the many-to-many (n:n) relationships are modeled in Access by linking both
of the tables to a third, instead of directly to each other, in two
one-to-many relationships, as
client 1:n classclients
class 1:n classclients
i know that appears to match your posted declarations:
One client can have many classes (1:M)
One class can have many clients (1:M)

my point is that it's important to define the relationships themselves
correctly:
One client can have many classes AND One class can have many clients
n:n
to make sure you then build the appropriate tables (clients, classes, AND
classclients) to support them properly.

hth


"lanjoudun via AccessMonster.com" u53027@uwe wrote in message
news:9895bf9daaa3d@uwe...
I think the major issue is the set up of the relationship.

One client can have many invoices (1:M)
One client can have many payment plans (1:M)
One invoice can have only one payment plan (1:1)
One client can have many classes (1:M)
One class can have many clients (1:M)
One trainer can have many classes (1:M)
One class can have many trainers (1:M)


June7 wrote:
If the query works then build a report to output the results, not save to
a
table. Basic principle of relational database design, Save Raw Data,
Calculate in Report.

I'm building a database for my personal training business, and currently
I
ran into a huge pickle and don't know how to bite it. My problem is
this, a
[quoted text clipped - 20 lines]
The query does all the calculations but I'm stuck as far as moving the
information into an account table or such.

--
Message posted via AccessMonster.com

http://www.accessmonster.com/Uwe/For...esign/200907/1