Results 1 to 7 of 7
  1. #1
    Silver Lounger
    Join Date
    Jun 2001
    Location
    Niagara Falls, New York, USA
    Posts
    1,878
    Thanks
    0
    Thanked 0 Times in 0 Posts

    LOOKING TO IMPROVE A2K PERFORMANCE

    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

  2. #2
    Silver Lounger
    Join Date
    Jan 2001
    Location
    Indianapolis, Indiana, USA
    Posts
    1,862
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: LOOKING TO IMPROVE A2K PERFORMANCE

    You can always do a little to optimize your code:
    <A target="_blank" HREF=http://www.microsoft.com/officedev/articles/movs101.htm>http://www.microsoft.com/officedev/articles/movs101.htm</A>

    HTH <img src=/S/salute.gif border=0 alt=salute width=15 height=20>

  3. #3
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: LOOKING TO IMPROVE A2K PERFORMANCE

    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.
    Charlotte

  4. #4
    Silver Lounger
    Join Date
    Jun 2001
    Location
    Niagara Falls, New York, USA
    Posts
    1,878
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Looking To Improve A2K Performance

    You Said

    <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.>

    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

  5. #5
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: Looking To Improve A2K Performance

    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.
    Charlotte

  6. #6
    Silver Lounger
    Join Date
    Jan 2001
    Location
    Indianapolis, Indiana, USA
    Posts
    1,862
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Looking To Improve A2K Performance

    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 <img src=/S/shrug.gif border=0 alt=shrug width=39 height=15>

  7. #7
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: Looking To Improve A2K Performance

    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!
    Charlotte

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •