Hmmmmmmmmmmmm,
Having already been quoted, I do not know that I have much (more) to offer. I would definitly agree that 40K records is a "small" data base and should not be a consideration re speed of the db. In fact, for a db with this few records, I am forced to wonder WHY it would have any real degree of complexity (" ...
very large and has many many functions and subroutines written in VBA ... "

.
It is also quite interesting that an "old" system would only have 40K records. For a general business app, that is probably only a few months of data (or less). Even for a relatively 'slow' business process, one would 'expect' that many records in a year.
So, my knee jerk reaction is that no one knows to "compact" the db on a regular basis - and that it probably hasn't been done in a LONG time. My Other knee jerk (the one which caused me to fall down) is that you are adding users to the system, but then with only 40K records, how many users can there (practially) be? Do the compact thing. If that doesn't DRAMATICALLY improve performance, re-post with some general discussion about the app:
How many
[tab]Tables
[tab]Forms
[tab]Queries
[tab]Reports
[tab]USERS (Overall)
[tab]Users (Max simultaneous)
[tab]does the app use MACROS (extensively)?
[tab]How many Modules?
[tab]How many Procedures?
[tab]What is the general intent/use of the app?
[tab]Is it "Split" (e.g. Seperate .MDB file for the data(tables) and the 'remainder'?
[tab]Is it a 'Secure' db (do you have to "Log On" to use it)?
[tab]does it appear to be slow only in certain situations, such as particular time(s) of the day, when certain Users are 'on', for sppecific operations (Daily report generation)? ...
[tab]Is there a regular routine to compact the db?
[tab]Is the db backed up on a regular basis? By a Network process? By the db ADMIN? What was the most recent verification that a BACKUP copy of the db was SHOWN to be 'operable'?
MichaelRed
mred@att.net
There is never time to do it right but there is always time to do it over