Below are checklist items (which anyone is free to add to), which I hope help troubleshoot any problems with a slow mdb as well as some tips on fixing slow-running computer problems:

Before reading the troubleshooting items, I wanted to make a special note here on using unbound forms for an mdb. Unbound forms is a great technique to improve the speed of your forms and especially ideal in a large-recordset environment. Although it should not necessarily be used to avoid troubleshooting why you've suddenly encountered a slower running mdb, it is something you should consider at design time as designing unbound forms will take you a longer time in developing (as well as modifying) your application. But the benefits of speed on your forms is something that will make you (and your users) much happier.

--------------------------------------------------------------------------------

Some things to check/do for speed issues:

1. Check for a slow network card in your pc (especially if you've upgraded Operating systems.) Slow Network Card + New Operating system/Other new installations can = slow performance.
2. Check your profile file (if large, this can slow things down.)
3. Check your msconfig for any new files which are now loading up during startup due to new installations (and using RAM). -Start->Run, then type msconfig. Look at the Startup tab. Some items can be unchecked to not load in startup (i.e. Adobe, Quicktime, etc...) I found that Adobe seems to a big culprit which ALWAYS tries to configure itself to load in the startup tab (and I've never found a specific need to have Adobe do this - you can still open your pdf documents after unchecking Adobe in the startup tab, they may just load a tad slower.) You'll need to reboot after making any changes and then check the box to "Not show MSConfig changes any more" in the message box which shows after re-boot so you don't continue to see the message box until you make MSConfig changes again.
4. Index/re-index fields in your tables.
5. Check the free space on the drive with the mdb and your drive.
6. Compact/Repair the mdb. Run the JetUtil program against your mdb. Use the /decompile switch when opening the mdb. Make sure you've debug-compiled your code.
7. Create a new mdb and import all the objects (last resort type item.)
8. Minimize code in forms since newer versions of Access loads all the code in the forms.
9. Create a simple mdb and compare speed.
10. Move the mdb to your local drive or a different network drive or folder.
11. Make sure you have sufficient permissions to the networked drive.
12. Watch for multiple comboboxes/dlookup and other commands which cause forms to open slowly. A big culprit is having multiple, multiple subforms (usually in tabs) which all load in the opening of your form.
13a. Use criteria to limit opening "ALL" the records in your form and instead records based on criteria (this will help if you have multiple, multiple subforms and are loading all the records in them as well.) Instead, if using tabs for your subforms, set the sourceobject of the subform in that tab in the OnChange event of the tab control.
13b. I like to avoid using the MSAccess Filter option and instead use criteria in the sql statement. I've seen a lot of problems stem from using Filter commands versus criteria. The Filter option seems to be especially problematic when it encounters "bad" type data in your tables.
13. Make sure no backups/virus scans are happening on your computer at the time.
14. Make sure no other scheduled tasks are happening at the time.
15. Try having the network guys/gals connect you to another switch.
15a. If using daisy-chain hubs, definately switch to a switchbox. Daisy-chain hubs can be detrimental for slow data returns on a network environment.
16. Using Windows Explorer, disconnect all network drives and then reboot/connect the drive with the mdb and try it. Then connect/map the other drives.
16a. Re-Link tables.
17. Make sure you have all the references in the mdb in code view. Missing references can slow an mdb down as well as cause other problems with code.
18. Try debugging the code on your computer to see if any errors show up anywhere.
19. Make an mde file from the mdb to see if that helps performance.
20. Have someone else log into the slow computer to see if it's computer related or your profile related.
21. Try a cloning technique (DBForums Code Bank) to help with speed issues (this has worked very well for me as it keeps each user in their own mdb - but you must utilize linked Access or SQL Server tables to use it.)
22. Hold down the shift key and open the mdb to bypass code. If the mdb itself still loads slow, it could be network related.
23. Defrag the harddrive (I personally recommend: PerfectDisk or Diskeeper).
24. Make sure all drivers are working correctly. Since Access is also dependant on a good printer driver, try changing the current default printer and see if that makes a difference. (Note: I've had issues where I had a bad default printer selected and the code in Access bombed out.)
25. Start->Run, then type Services.msc. Look for any new services in which Status = Running and Startup = automatic. New software loaded (ie. especially things such as anti-virus/Anti-Spyware programs, Adobe, CD-Burning software, SQL Server, Disk Management software, Network configuration changes, PunkBuster (network gaming), Steam (network gaming), etc..) often sets itself to automatically start in the services (not to be confused with the MSConfig-Startup tab.) Other than your anti-virus software (which should NEVER be changed), you can possibly change some items to Startup "Manually" (ie. double-click on the item in the listing to change the startup type.) Be careful though when doing this and research on the item you change BEFORE you make it startup manually!
26. Use application tools such as Registry Mechanic or Tune-Up Utilities Pro to find problem areas in your registry and defrag/optimize it (I've found these are very good tools which help with overall computer speed.)
27. As always, run your anti-virus and especially your anti-spyware/malware programs and fix/repair/remove problems which would tend to slow things down (especially spyware/malware as this seems to be a big culprit for slowing things down while viruses are more likely to just destroy things and make your computer or certain applications unusable.) Note here: Internet Explorer is a BIG target for viruses/spyware/malware. You may want to consider Mozilla Firefox as another possibility for connecting to the internet (I use both.) For Internet Explorer, things such as: Add-ons/activeX controls which automatically load in IE have often been the culprit. Firefox seems to handle and protect you better from bad add-ons/activeX controls.
28. Download and run HiJack and post the results on some forums which troubleshoot HiJack created files and show if your system has been infected.
29. Download and run a "Rootkit" tracing program to see if you were infected with a rootkit type program.
30. Although a lot of anti-virus programs look for keylogging programs, if you "suspect" that someone else is tracing your keyboard entries (which I've personally found is rare), this could slow things down. There are special keylogging detection software programs.

Questions: Does it run slow for other users on your computer? If so, it could be something like a missing reference or lots of stuff opening in the startup. Do other mdb's run slow on your computer or is it just this mdb? Do other programs such as Word, Excel run slow? Is there a certain time it runs slow or is it all the time? Are there certain forms loading slow and other forms load faster? Does it just run slow when you're loading the forms or does it run slow when you get behind the scenes and edit code or run a query? Determine if it's the forms by closing all forms and running a query. How many records are in the mdb? What is the size of the mdb? Are all the recordsets closing? Are there any graphics or objects being stored/loaded on the forms.

** Monitor the memory being used by opening Task Manager and see how much CPU time/memory Access uses when it is open (Processes tab). Look for other program's CPU usage. If the Access file keeps growing and growing in size, troubleshoot code for problems. Perhaps multiple forms opening and recordsets not being closed which don't seem as apparent on other computers. Although not recommended, you can right-click on Access in Task Manager and temporarily set the priority higher to see if it has an affect. While an MSAccess is open, the MSAccess mem usage size in the process tab should grow as forms/recordsets are opened. It should NOT continuously grow though (ie. beyond a 100meg for example.) You should see a point where it "steadies" and growth happens very minimally if at all. I once had an MSAccess mem size which continued to grow no matter what. After revisiting the code, I found that I wasn't closing recordsets. Once I did this, MSAccess stabalized at a certain memory usage. An interesting note here: if you re-utilize the same naming of variables (ie. rs for recordsets - Dim rs as ADODB.recordset) and other variable names, versus always using a new and different name, you'll find that MSAccess will actually have less tendency to grow.

Attached are several, several XP hidden secret trick documents in the zip files (FOR ADVANCED WINDOWS USERS), which I found on a website and I've attached to read. There are a few tricks worth reading but I BY NO MEANS have any claim to any of the techniques or accept any responsibility for using any of them (again, only for advanced users as you should know what your doing and the possibility of making your computer unstable or unusable when utilizing any of the techniques found in these documents).