How do I create a unique subdatasheet for each item in my query? .

[Guest]

I need to keep a log on each item in my database.

Let's just say I have a list of customer and various attribues as column
headings on my table (Customer, city, state, county, etc.)

I want to keep records on how each customer concern was addressed and the
date, so that I have a table/log of complaints, tasks, and task resolution
for each customer. I would like to keep this information stored as a
subdatasheet, but if there is any other way to get the same fuctionality, it
would be great to know.

I am a beginner Access user, so if the solution is very obvious, please
excuse me.

Thanks.

 

[John W. Vinson]

I need to keep a log on each item in my database.

Let's just say I have a list of customer and various attribues as column
headings on my table (Customer, city, state, county, etc.)

I want to keep records on how each customer concern was addressed and the
date, so that I have a table/log of complaints, tasks, and task resolution
for each customer. I would like to keep this information stored as a
subdatasheet, but if there is any other way to get the same fuctionality, it
would be great to know.

I am a beginner Access user, so if the solution is very obvious, please
excuse me.

Thanks.

First off... don't get hung up on data PRESENTATION (subdatasheets for
example). Information is not stored on the screen; it's stored in Tables.
Tables can be displayed in datasheets and subdatasheets, or - much better - on
Forms and Subforms.

You need one Table for each relevant entity type. A Customer is one type of
entity; a Complaint is a different type of entity; a Task is yet another type
of entity. You will want one table for each. You need to know how the entities
are related to one another; typically this will be a one to many relationship
(each Customer may generate zero, one, or more Complaints; each Customer may
involve zero, one, or more Tasks; each Task may have zero, one or more
Resolutions). This is just an example - you need to analyze your own business
needs and develop a "normalized" set of tables to store the data.

You would then create Forms with Subforms (a form for the "one" side of a
relationship, a Subform for the "many") for use in entering and editing the
data in your tables. It's best NOT to use table datasheets for any purpose
other than debugging: they're very limited in their capabilities.

See the references below, especially the "Database Design 101" links on Jeff's
site:

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

John W. Vinson [MVP]