Justin

Roger offered a couple of great resources to use in setting up a
well-normalized table structure. Consider re-posting a brief outline of
your current design for comment...

For example, your situation might call for:

tblContract
ContractID
ContractorID
ProjectManagerID
Title
Description
ContractType
OriginalAmount
OriginalStartDate
OriginalEndDate
...

or maybe some of these are not germane to what you are doing, while others,
unmentioned, are critical.

There are proprietary constrictions on releasing structure or application
for the system I recently designed, and, as above, you really need to have a
clear picture of what YOUR requirements are, rather than trying to make your
data/needs fit someone else's model.

--
Good luck!

Jeff Boyce
Access MVP

"justin" wrote in message
...
Thanks for your post.
I've read the 4 rules to normalization several times over
now.
Yes, before yesterday basically all I had was a
spreadsheet made in Access. Which doesn't really do
anything.
So, from the original table I made with the following
fields:contract#, contract name, our contact person, their
contact person, date recieved, start date, end date, route
date, completion, $ amount, contract type, account#, PO#
(if needed), and who entered the data, I've broken it down
into two tables thus far.
I removed all the date fields, and put them into their own
table. I also created a field ContractID in both tables
that is a autogenerated number and the primary key in the
original table. Then I created a relationship btw. the
ContractID fields in both tables.
I am on the right track with any of this?
Should I break that original table up even further? I
don't see the need to, but then again, I've never used
Access before, so I don't really know what I'm doing.

Would it be possible for you to elaborate on
the "contracts tracking" database you recently created?
Like tables involved, and their relationships btw. each
other?

Thanks for the help
-Justin