Access (97 and 2000) loads each module into a single block of memory. If you have a lot of code, and it's all in one module, you'll need a BIG memory block for it.
In a small-memory machine, that could be a problem, but it would occur only when the database was opened. Once it's open, you'd be unlikely to have any further memory problems in the Access window. You might, however, put a strain on other applications trying to run in what's left, and the result could be to slow everything down because of Windows swapping memory back and forth to disk.
If memory isn't a problem, though, having all your code in one module could actually make it run faster, because Access won't have as much memory management overhead. (It would still have to load form modules separately, so there would still be some overhead.)
The downside in that case, though, is that all your code would have to be loaded when the database is opened, which could make your startup slow.
Also, if anything happens in your application database that causes it to be decompiled, you might experience delays while the code is recompiled. You could prevent this by putting the module in a library database, and establishing a reference to the library database from your application database, but of course then you have another file to distribute to your users. (Not that that's a big hairy deal, in most cases.)
If you decide to try this, consider putting related procedures near each other in the module. Not only will this make it easier to work on the code in the future, but it can reduce the amount of page swapping that occurs at runtime, because procedures which call one another will be more likely to reside in the same page of memory. Rick Sprague
