Repeating data in table

[marine8105 via AccessMonster.com]

I am trying to start simple and understand some of creating a dbase. However,
I want to develop a dbase to handle bank statements. Each client (using ssn)
can have several bank accounts. I have set up the form to gather the client
info, bank info, and of course the account numbers. How do I create a form
to allow me to enter deposits, other increases, checks, other decreases,
balance? I want to gather this information without having to input the ssn
and account number each time.

I am looking to input the account number, which will tie to the client ssn,
and then input the deposits and checks (along with the date of the statement)
for each month over what might be years. I can then query using dates and
ssn.

Thank you for any help.

Mike ONeil

 

[John W. Vinson]

I am trying to start simple and understand some of creating a dbase. However,
I want to develop a dbase to handle bank statements. Each client (using ssn)
can have several bank accounts. I have set up the form to gather the client
info, bank info, and of course the account numbers. How do I create a form
to allow me to enter deposits, other increases, checks, other decreases,
balance? I want to gather this information without having to input the ssn
and account number each time.

I am looking to input the account number, which will tie to the client ssn,
and then input the deposits and checks (along with the date of the statement)
for each month over what might be years. I can then query using dates and
ssn.

Thank you for any help.

Mike ONeil

STOP!!!

You're evidently missing the most basic principle of relational databases:
each type of Entity gets its own Table, and each individual Entity is
represented once and only once.

You should have a table of Clients, with SSN as the primary key and
biographical information in other fields. That information should be stored
ONCE.

You should also have a table of Accounts, with an AccountNumber as the primary
key, a SSN field as a link to the table of clients, account-specific
information, and *absolutely nothing* about the client.

Then you need a table of transactions, with a primary key (perhaps an
autonumber), an account number (*but no SSN*, you would link to that via the
accounts table), amount, transaction type, transaction date, etc.

You can use a Form based on a parent table with one or more Subforms based on
the child tables. The Subform's master/child link feature will fill in the
linking field (e.g. account number) without your needing to type it - or for
that matter, even *see* it.

Take a look at some of these tutorials for good examples:

Jeff Conrad's resources page:
http://www.accessmvp.com/JConrad/accessjunkie/resources.html

The Access Web resources page:
http://www.mvps.org/access/resources/index.html

Roger Carlson's tutorials, samples and tips:
http://www.rogersaccesslibrary.com/

A free tutorial written by Crystal:
http://allenbrowne.com/casu-22.html

A video how-to series by Crystal:
http://www.YouTube.com/user/LearnAccessByCrystal

MVP Allen Browne's tutorials:
http://allenbrowne.com/links.html#Tutorials

 

[kc-mass]

As you start developing data bases one of the things you want to understand
is info security.
There is no reason to, and a lot of reasons not to, use a social security
number in a database.
Your band records your checks and deposits by your account number not by
SSN. They do that for good reasons. If SSNs are stored, displayed and
printed they and perhaps your self may be liable if the customer's identity
is compromised.

Read up on the subject and I think you will agree.

Kevin