Hum, access has not been cpu bound for a very long time. any spec machine
over 600, or 800 mhz is about all you need.
You can double, or even triple the processing..and you will not notice one
bit of differences.
ms-access spends most of it time waiting for the diskdrive (or, worse..if a
network is involved, waiting for ht network).
You might give a bit more information as to where the data is being pulled
from (is a network involved...or a local hard disk??).
However, cpu is generally not a problem. The only real way to speed things
up is to ensure that your query can use proper indexing etc to REDUCE the
amount of data transferred in the first place. So, often making sure
ms-access can use a index can speed things up by a factor or a 100 or even
more. So, increasing processing won't help...but proper design will make all
the difference in the world...
Your problem is not processing...but i/o speed....
If your database is split, and you have a network involved, then there is
likely MUCH you can do to speed this up.
Further, remember, some code is much like using a helicopter to cross a
street. By the time you get the helicopter up to speed, and the machine
becomes airborne..I could have EASILY crossed the street by foot. Gee,
walking is faster then a helicopter?
Remember, opening a reocrdset inside of loop can slow the code down to a
crawl. (ms-access has to wait for the file system to open the table..and
load up things...this takes for ever). In the time it takes to open and
setup a reocrdset...ms-access usually can have loaded about 100,000 records.
So, for example if you have code that loops, and each iteration of the loop
creates a reocrdset, then have to eliminate that (it is like starting up the
helicopter each time to do something....).
