Thanks...but I do have a few questions. Since being very new I don't know
what certain things mean. What a str, dt (date?), bin, mem (memo?), int
and cur (current?). Are these things you type into the field name or is it
specifying a type of field setting?

str, dt, bin, mem, int and cur are prefixes. They refer to the field type
(str = string, dt = date, mem = memo, int = integer and cur = currency. Use
of prefixes when creating table fields can be helpful in the future when you
are designing queries, forms, etc.

In the tblMembers, the MemberPK. If you meant that the Member ID # is the
PK, that will NOT work as I had previously mentioned. I will have to use an

auto-number field for the PK. Was going to name it PID or something so that

I won't get confused with the Member ID field.

Yep! The MemberPK is an autonumber field – simply a unique identifier Of
course, you can name it anything you like... I would however suggest
something that specifies its origin is tblMember.

2nd tblMembers question.....NewsLetterMethod. You say it stores info from a

form dropdown. A form drop down on the table? Or is this something that
happens once I start creating forms? Also would that mean that I can't
enter
this info until after I have created the forms and I'd have to go through
each member via the form to input the correct info?

Yes, the intent is that the information would be stored here. While under
daily circumstances, you would enter new data via a form, entering existing
data would depend on your method (import or direct entry – direct entry into
the table could be done, so long as the entries are consistent. The values
entered (ex: Email or Post) would then be the rowsource for a combobox aka
dropdown on your entry form, with the controlsource set for the
strNewsLetterMethod field. This way, anytime you make a selection, it will be
stored in the proper field.

Bear with me here as now I've gotten confused again. tblMembership:
intMemberFK (foreign key to tblMember...is this the primary key field from
the tblMember?) Is the MembershipPK here an a auto-id field?
intMembershipType foreign key to tbleMembershipType I assume is the PK in
that table?

Each of the PrimaryKeys for the tables above is autonumber type. In the case
of intMemberFK, it is storing the MembershipPK. This is the basis for its
relationship with tblMember. The one to many relationship allows multiple
instance of the MemberPK in tblMembership. Additionally, intMembershipTypeFK
would store the MembershipTypePK, in effect creating a many to many
relationship between tblMember and tblMembershipType (meaning that while not
required, each member could theoretically have multiple memberships as
indicated in the original post)

Part of what's confusing me on the membership table is that I thought (not
sure I can explain correctly) that it had to have equal info. If the FK is
the PK from the member table, that's close to 1000. the MembershipType FK
to
the MembershipType table would have only 5.

tblMembership would store multiple instances of MembershipTypePK, creating a
one to many relationship. Multiple people would have the same membership type,
so each of those 5 membership types could appear multiple times in
tblMembership, for each member.

tblMembershipType: MembershipTypePK - auto-id field?

I just answered a question myself by actually reading furthur. In the
tblGroup, I see that's where the actual MemberID number would go. So the PK

in the tblMember is an auto-id field. I assume the GroupPK field is an
auto-id field?

tblGroup: GroupTypePK another auto-id field I assume?

Yes, each of the PK fields are autonumber.

tblPayment: Payment PK again another auto-id? Probably wouldn't put the
payment amount. We just need to know if & when they paid the current year.

Also how can I keep track of more than one year? We like to keep data for
at
least the current year & previous year.

intMemberFK is storage of the MemberPK, again creating a one to many
relationship with tblMember. This allows any number of payment records for
each member.

Last question for now. It looks like some of this data will only be able to

be entered via the forms so that I'm sure the proper info gets into the
proper place....PLEASE tell me that I can at least import from Excel the
name, address, phone, e-mail & DOB information?

Import should be no problem, so long as the information is of the proper type.
Excel and Access play very well together!

My plan was to figure out what fields would be in the main table and then
edit the information that I exported out to Excel to match that so that I
could import it into a new table and then add the MemberPK field to it. Is
that ok? I don't want to have to type in all the information for almost
1000
records. Or do I really need to setup all the tables first and then enter
all data via the forms.....I'll be here forever.

Setting up the tables first is definitely the way to go. One way I’ve done it
in the past is to import the Excel sheet as its own table with an autonumber
PK added. Then use queries to create the related tables, including the
necessary fields and the PK into the FK field, copying the data into the new
tables. After the data is checked and confirmed to have copied over properly,
you can actually delete the copied fields from the first table, removing the
duplicate data. That first table then would be your tblMember. I’ve set up a
layout sample to help you visualize the relationships. It’s in pdf format,
www.a2zpa.com/Relationships-for-MembershipDB.pdf

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