Alright so far change the relationships, so now every invoice is linked to
one payment method a 1 to 1 method, my next problem is now every invoice is
alotted a number of sessions, I want to limit the number of records entered
per invoice by the session number, ex: client buys 6 sessions, so the invoice
can only be linked to 6 sessions, I already limited the session criteria so
it can only allow sessions between invoice start and end period. I'm
wondering how I should place these validations in.

tina wrote:
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

I think the major issue is the set up of the relationship.

[quoted text clipped - 15 lines]
The query does all the calculations but I'm stuck as far as moving the
information into an account table or such.

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

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