I only have one table - but many columns. I have looked at Crystal's tutorial
and found it slightly helpful, but also confusing - as am not fluent in
computer tech speak.
Relationships are between different tables. If you have only one table then
there is nothing you can relate it to! It's like asking about the
relationships in a family which consists of only one person.
However, if you have only one table with many fields... perhaps you actually
have a spreadsheet, not a relational database. Looking back in the thread you
say
My database is for Personnel Records, it contains information that records
all staff's personal details and also training info, hours worked etc.
This should NOT BE STORED IN ONE TABLE.
Each Table should represent instances of one real-life entity - a person, a
thing, an event. A person is a type of entity; a Person entity has
"attributes" - useful distinct chunks of information - such as FirstName,
LastName, Birthdate, etc. These should be fields in the People table.
But something like training information is *not* appropriate in a People
table. Instead you should have a one to many relationship between the People
table and a Training table, so that if Joe Schmoe has had training in Safety
Procedures, Vehicle Maintenance and Forklift Operation, you would have three
*records* (not three fields) in a Training table for him.
Hours worked is an even clearer instance. Each person will - presumably - work
various hours on many days. You certainly could NOT have a database with a
field for each time they work!! Instead you would have - again - a second
table, with fields for the PersonID (a link to the primary key of the people
table), and perhaps fields TimeIn and TimeOut, a field indicating where they
worked if that's variable, etc.
You're using a relational database. Go back to Crystal's tutorial, or the
Database Design 101 links in Jeff's site, and study. This program has a steep
learning curve; with Word you can sit down, open the program, and start typing
(and then spend months learning how to actually use the power of the program
to good advantage). But working with Access requires more investment up front
- you need to understand how databases work, or you'll get yourself into a
badly flawed design.
John W. Vinson [MVP]