No, I wasn't aware I needed a separate table for the transactions. So, I
think I would make a copy of the members table called "transactions" correct?
No.
A member is a member, and has attributes such as LastName, FirstName,
DateJoined, etc.
A Transaction is a different kind of entity; a transaction doesn't
have a last name but it has (I presume) a transaction date, and other
information about the transaction. Normally you would use a Form for
the "one" side (members?) with a Subform for the "many"; the "many"
side table would have a MemberID (but NO other member information).
and the same with the members form? If that is indeed the case, how then to
make a one to many, which table would be on the right and left side? I'm
truely a beginner at this. Thank you.
I don't know your business model, so I can't be sure; ask yourself
which sentence is correct:
Each Member can have many Transactions, but every Transaction pertains
to one and only one Member.
or
Each Transaction can involve many Members, but each Member is involved
in one and only one Transaction.
or
Each Member can have many Transactions, and each Transaction can
involve one or more Members.
These would correspond to One to Many Members -> Transactions; One to
Many Transactions -> Members; and the third to a many to many
relationship, which needs a third table.
Check out some of the introductory tutorials linked from these
websites; the Database Design 101 links on Jeff's webpage should be
particularly relevant.
Jeff Conrad's resources page:
http://home.bendbroadband.com/conradsystems/accessjunkie/resources.html
The Access Web resources page:
http://www.mvps.org/access/resources/index.html
John W. Vinson[MVP]