LOOKING TO IMPROVE A2K PERFORMANCE

Topic

New Reply

LOOKING TO IMPROVE A2K PERFORMANCE

Using Access 2000 (9.0.4402) SR-1

My database scenario involves a Front End and Back End concept. I’m looking for anything that can be done to improve performance.

I have found the following items from other forum posts that have helped:

1. Name AutoCorrect is not checked (disabled)
2. Subdatasheet Name is set to None. MSKB Q261000

Are there any other A2K items I can check that will further improve performance?

John Graves

NBS7335

Reply | Quote

Replies

You can always do a little to optimize your code:
http://www.microsoft.com/officedev/articles/movs101.htm

HTH

Reply | Quote

And make sure your queries are built for speed. It’s very easy to build bad/slow queries in Access. Sometimes simply rebuilding them from scratch, a bit at a time, will show you where the problem arises and you can find a faster way to do it. Although it’s considered a BAD thing to layer queries with criteria in the underlying queries, sometimes it’s the only way to make them run. But don’t repeat criteria at upper levels that are already in effect at lower levels.

I would also turn off any table lookups in your tables. Since these are queries themselves, they create overhead you don’t need in other queries. Do the lookups at the highest practical level in the queries.

Reply | Quote

You Said

As a newbie I was taught this and using it extensivily through my tables.

Do you remove table lookups after you build your forms with wizzard?

Or do you build your form combo boxs from scratch?

John Graves

Reply | Quote

These seem very handy because you get a combobox automatically when you drag the field onto a form, but they always cause me confusion because I can’t see the actual value in the table and performance problems in forms because they’re still there underneath the form, so I avoid them.

I don’t use the wizards to build my forms unless I’m just throwing one together as a temporary thing that I’ll throw away or actually do need ALL the fields on the form (very rare), and I prefer to tell Access the kind of control I want rather than letting it presume to tell me. When I want to see the related value, I build a query and save it for that purpose.

A lot of stuff like that is included in Access to make it more novice/end user friendly. However, if you’re actually going to develop in Access, you need to learn to get by without it to squeeze all the performance you can get out of your application. Even if it runs fine on your machine, it may not run fine across a network. And even if it runs fine from your workstation, it may not run as well on a workstation linked to a different server or one that is set up differently. For that reason, I develop for a standard 800 x 600 display, never higher, and I try to optimize the app as much as possible.

Reply | Quote

Charlotte,

I’m just curious if there’s any performance or stability-related reason you use 800X600 display instead of anything bigger.

Although I develop my applications for 800X600 users, I find more screen real estate very helpful for development purposes (such as 1024X768).

Just curious

Reply | Quote

Not performance, no. It’s a question of usability, if there is such a word. I stick to that because it’s the lowest resolution any target machine is likely to have. It’s one thing to see a small form in the middle of an enormous screen, but it’s quite another to see only a part of the form and scrollbars because the developer built it for a much higher resolution.

I’ve also found that using a high res for development can bite when you’re building queries. I’ve been sent dbs with queries that were built in the highest possible resolution and stretched out to show the full field list for each table, and I couldn’t work with them at all without rebuilding them for 800 x 600–I couldn’t ever get to the grid on the darn things!

Reply | Quote