View Single Post
  #5  
Old July 9th, 2009, 09:12 PM posted to microsoft.public.access.tablesdbdesign
jmoore[_2_]
external usenet poster
 
Posts: 81
Default do I need more indexes?

Some of my queries are slow to open. The object that takes the longest time
just to open is the aggregate report. And when trying to make changes in
design view, there is a long delay after clicking on a control and when it
becomes active. The same with trying to move a control - very, very slow. I
don't know about adding a new record yet as I have to make some changes
before the next batch of information comes through and I thought I would try
to address this problem at the same time.

your general rule of thumb about indexes is what I read (sorry, don't
remember which post) and is why I added another index. However, it does not
appear to help. The printer is set to my default printer.

Thanks again for all help.

"Jeff Boyce" wrote:

Define "response time" ...

If you mean "how long it takes to add a new record in", then yes, when
Access has to add the new data AND an index, it takes longer. If you don't
have a high-volume data-entry business, you won't notice how much longer.

If you mean "how long it takes to retrieve data via a query", then no, a
properly-indexed set of tables will generate results faster.

A general rule of thumb (i.e., not set in stone) is to index any field that
is used as a selection criterion, as a join, or as a sort. Of course, if
you only have two possible values (e.g., Male, Female), the index really
won't help.

Slow to open is one thing ... slow to open in design view may be something
else. Do you have a printer "assigned" to the report?

Regards

Jeff Boyce
Microsoft Office/Access MVP


"jmoore" wrote in message
...
After reading several posts here I have changed all of the lookup fields
to
text fields in my table and deleted the relationships to the lookup
tables.
I came to this area looking for a solution to slow response time. Again,
after reading several posts, I suspect it is due to the database design,
but
it is what I have to work with.

Other than the lookup tables, there are only two related tables. If it
would be helpful, I can remove the lookup tables.
tSample (with the major fields listed below)
Key (primary key)
CNTYNAME
ID
Strata
Sample

tReview
ReviewKey (PK)
Key (FK)
A1
A2. . .
B1
B2. . .(in total there are over 60 number fields and 50 memo fields).

I read that creating indexes will increase response time. Will creating a
unique index from two fields in addition to the PK increase response time
(e.g., in tSample, a unique key comprised of CNTYNAME and ID)?

All was going well for the individual county reports, but I had problems
when an aggregate report was needed at year end. I was able to solve the
problem with advice obtained through this site. First, I created a union
query (qUnion); a crosstab query based on the union query
(qUnionCrosstab);
and combined qUnionCrosstab and qReviewCountCrosstab into one query
(qCrosstabsCombined) for the aggregate report. The aggregate report is
extremely slow to open and painfully slow in design view.

Will it help to create additional indexes? If not, I can live with this
report as it is since I only need it once a year. I don't know how to
change
the design and transfer the data.

Thanks for any tips for improvement. I am very grateful for the great
information I have found here.