Unbound fields

On Thu, 23 Aug 2007 01:20:02 -0700, Rhianne
wrote:

well, what is the purpose of a query? If I knew that then I could decide if I
need one or not.

You can (and will) use queries for many purposes. Here's some things you can
do with queries that you cannot do with tables:

- Select only a subset of the fields in the table
- Select only a subset of the records (rows)
- Sort the records
- Include calculated fields
- Link to other tables to "look up" values


John W. Vinson [MVP]

I have now created a query and am beginning to understand why it would be
helpful to me to have it.

Is there anything else that needs doing? Do I need to create relationships?

Thank you!

"John W. Vinson" wrote:

On Thu, 23 Aug 2007 01:20:02 -0700, Rhianne
wrote:

well, what is the purpose of a query? If I knew that then I could decide if I
need one or not.

You can (and will) use queries for many purposes. Here's some things you can
do with queries that you cannot do with tables:

- Select only a subset of the fields in the table
- Select only a subset of the records (rows)
- Sort the records
- Include calculated fields
- Link to other tables to "look up" values


John W. Vinson [MVP]

On Fri, 24 Aug 2007 02:56:02 -0700, Rhianne
wrote:

Is there anything else that needs doing? Do I need to create relationships?

If you have two tables... yes, you should have relationships (BEFORE you start
messing with queries or forms...!!!) Relationships ensure that you have (say)
a real Department in existance before you assign an employee to a Department.


Have you read any of the tutorials? Jeff's Database Design 101 links and
Crystal's tutorial would be worth some time invested before you get too deep:

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

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

A free tutorial written by Crystal (MS Access MVP):
http://allenbrowne.com/casu-22.html

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

John W. Vinson [MVP]

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.



"John W. Vinson" wrote:

On Fri, 24 Aug 2007 02:56:02 -0700, Rhianne
wrote:

Is there anything else that needs doing? Do I need to create relationships?

If you have two tables... yes, you should have relationships (BEFORE you start
messing with queries or forms...!!!) Relationships ensure that you have (say)
a real Department in existance before you assign an employee to a Department.


Have you read any of the tutorials? Jeff's Database Design 101 links and
Crystal's tutorial would be worth some time invested before you get too deep:

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

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

A free tutorial written by Crystal (MS Access MVP):
http://allenbrowne.com/casu-22.html

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

John W. Vinson [MVP]

On Tue, 28 Aug 2007 01:42:00 -0700, Rhianne
wrote:

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]