comments inline.

"lanjoudun via AccessMonster.com" u53027@uwe wrote in message
news:98a3f758632a3@uwe...

Alright so far change the relationships, so now every invoice is linked to
one payment method a 1 to 1 method,

if you truly have a one-to-one relationship between an invoices table and a
payment methods table, i'd say you have a problem. remember BOTH sides of
any relationship must be defined. each invoice may have only one payment
method, but can each payment method *really* be assigned to only one
invoice? so if one invoice is assigned "cash" payment method, no other
invoice can be paid by cash? i doubt that's what you want. rather, i'd guess
that in reality you have a one-to-many relationship between payment methods
and invoices: one payment method may be assigned to many invoices, but each
invoice may have only one payment 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.

yes, that's do-able, at the form level. but i really recommend that you
STOP, turn off your PC, and study up on relational design principles before
you go any further. for more information, see
http://home.att.net/~california.db/tips.html#aTip1

hth


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