Performance Wizard

  • Thread starter Thread starter azu_daioh
  • Start date Start date
A

azu_daioh

Can someone please explain this to me?!? I tried searching for answers
but got me nowhere.

I used the performance wizard and got the following results:

#1 - 11 text boxes with 11 labels, 7 buttons, 1 check box, 2 combo
boxes = 32 controls
#2 - 11 text boxes with 11 labels, 2 buttons, 1 check box, 2 combo
boxes = 27 controls
#3 - 9 text boxes with 9 labels, 2 buttons, 1 check box, 2 combo boxes
= 23 controls
#4 - 9 text boxes with 9 labels, 7 buttons, 1 check box, 2 combo boxes
= 28 controls

When I run the performance analyzer on #1 and #2, it was recommended
to use fewer controls.
When I run the performance analyzer again on #3 and #4, no
recommendation was given.

So is it better to use more command buttons than more text boxes?

This is one of my attempts to speed up the database stored on a
network. I already tried the other suggestions I found (normalization,
split DB, subdatasheet name, auto name, compacting, using A2003, etc)
but the database is still slow.

The database has 18 tables, the main table contains about 21K
records. I did a search using "lastname" (which is indexed) and using
a shared DB, it took 4 minutes to load the next form with the result.
It took longer (20-30 minutes) using split DB. So, I'm trying every
bit of suggestions I could find to help speed up the database.
Unfornately, we can't do any modification on the network side. Our IT
folks refused to provide support in Access so we're on our own here.

Any help or tip is greatly appreciated. Thank you.
 
On Tue, 15 Jul 2008 16:00:08 -0700 (PDT), "(e-mail address removed)"

The performance wizard should not be taken too literally. Frankly
those suggestions are not very helpful in my mind, since they don't
take the business requirements into account. One or two dozen controls
on a form is not excessive.

The webserver at www.granite.ab.ca is currently experiencing technical
difficulties, but once it comes back, look there for the Performance
FAQ.

You must be leaving something important out of your description,
because a lookup by Lastname in a 21K table should return within a
second. Perhaps you'd want to hire a professional to look into this.
"Microsoft Solution Provider" in your Yellow Pages may be a good place
to start.

-Tom.
 
On Tue, 15 Jul 2008 16:00:08 -0700 (PDT), "(e-mail address removed)"


The performance wizard should not be taken too literally. Frankly
those suggestions are not very helpful in my mind, since they don't
take the business requirements into account. One or two dozen controls
on a form is not excessive.

The webserver atwww.granite.ab.cais currently experiencing technical
difficulties, but once it comes back, look there for the Performance
FAQ.

You must be leaving something important out of your description,
because a lookup by Lastname in a 21K table should return within a
second. Perhaps you'd want to hire a professional to look into this.
"Microsoft Solution Provider" in your Yellow Pages may be a good place
to start.

-Tom.
Click to expand...


Thanks Tom. The lookup only took seconds from my desktop but once I
opened the DB from the network, it took 4 minutes for the result to
come up. The database is shared to multiuser so it needs to be on a
network. I also tried splitting the DB (BE/FE) but it took
considerably longer than 4 minutes.
 
[email protected] said:
This is one of my attempts to speed up the database stored on a
network. I already tried the other suggestions I found (normalization,
split DB, subdatasheet name, auto name, compacting, using A2003, etc)
but the database is still slow.
Click to expand...

Did you try keeping a bound form open all the time or a recordset open
against a linked table?
The database has 18 tables, the main table contains about 21K
records. I did a search using "lastname" (which is indexed) and using
a shared DB, it took 4 minutes to load the next form with the result.
It took longer (20-30 minutes) using split DB.
Click to expand...

Do you have an index on the lastname field?

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
Thanks Tony for the post.
Did you try keeping a bound form open all the time or a recordset open
against a linked table?
Click to expand...

For the split DB? I don't think so. I have to research how to do this
and try it again.

Do you have an index on the lastname field?
Click to expand...

Yes, the lastname field has an index (Yes-duplicate OK)

Thanks,
Sharon
 
[email protected] said:
For the split DB? I don't think so. I have to research how to do this
and try it again.
Click to expand...

That's likely the most important performance item you can do
especially if someone else is already accessing the backend.
Yes, the lastname field has an index (Yes-duplicate OK)
Click to expand...

I had to ask. <smile>

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
Back
Top