You will need a customer table containing customer name, address, phone, etc.
It can also include preferred contact method and things like that, but let's
leave that aside for now. You should be able to describe a table's function
in a single sentence without using the word "and" (except for Name and
Address and things like that, as opposed to Name and Appointments, which is
not good).
Each row in the table is a record. Each cell in the table grid is a field.
A database table is not at all the same as a spreadsheet row. Spreadsheets
can perform calculations and things like that, but a database table is just a
bucket of information. Calculations, sorting, and anything else you want to
do is handled somewhere other than in the table.
Every table needs a primary key (PK), which is a unique identifier attached
to every record. One way of handling this (and the easiest way for
beginners, IMHO) is to use autonumber data type (which is assigned in the
table design view). The PK is also assigned in table design view. Your
customer table might be something like this:
tblCustomer
CustomerID (primary key, or PK)
FirstName
LastName
Phone
etc.
Then you would have an accounts table:
tblAccounts
AccountID (PK)
CustomerID (foreign key, or FK)
Account Details
Without knowing anything about the nature of these accounts I can't suggest
what fields the table may contain, so I have left it at Account Details for
all the rest of the fields.
Note the FK field. This is established by building a relationship between
CustomerID in tblCustomer and tblAccount. See Help for more about
establishing a relationship, and post back if you have specific questions.
Once you have the tables and relationships you can build some queries.
Queries are a way of sorting and manipulating table data. For instance, you
can build a query based on tblCustomer, sort by LastName, and combine
FirstName and LastName in a FullName field in the query. You will NOT store
the combined name. This is very important. You don't need to store it. You
can see it whenever you want.
You can base a form on either a table or query. The form treats each the
same as the other. Autoform is one way of putting a form together quickly so
that you can experiment. See Help for more.
Here's what I suggest to get started. Make a query based on each of your
tables. Name them qryCustomer and qryAccounts. Use autoform to make a form
out of each query. Name them frmCustomer and fsubAccounts. With frmCustomer
open in design view, drag the icon for fsubAccounts onto it and let go. You
should now have a subform. Switch to form view and enter a customer name and
information, and enter some account information into the subform. Add
another record to the subform. Now create a new record on the main form, and
some more account information for that customer. Keep it simple. After you
have done this a few times, take a look at the tables.
I have used a naming convention for tables, etc. It is sound practice.
Similarly, when you add text boxes and so forth to a form, use a naming
convention for those controls (as they are called). Try a Google groups
search for Access naming conventions or something like that, and name
everything so you can identify it later. This is just my suggestion and not
a requirement, but I really think you will find it makes life easier. Also,
I avoid spaces in names. I would name the table field FirstName, and make
the caption First Name if you like, but keep the spaces out of the "official"
name. Optional, but again it can be very helpful.
Experiment a bit and post back with the questions that will surely arise.