Those were just five different ways you could have gone. (a) is what I would have suggested too. I'm going to guess the main reason for the speed issues is bad queries (m*n joins, no/few indexes etc). The best solution is often a rewrite in these cases.

What I meant by (b) was to put the entire database in RAM and let users access it by logging on to the server directly. You can put the MDB files on a file-server network share (like P:\Database\Company.mdb) and 10 people can use it at the same time as long as they all have Access 97 on their local machines and have read/write access to the P:\Database folder. Instead of doing it this way, try this for super speed: setup a fast Windows server with tons of RAM, create/format a 2GB-16GB partition as drive D:, install SuperVolume to load that entire drive D: to RAM. Move the MDB files here.

Don't make users open the MDB files from their PCs directly. Let them log on to a Windows Server as Terminal Server (TS) users and access it from the D: drive. If you have some money, install Citrix so logging on to the TS could be done by just visiting a website and logging in. This would let people from all over the world use the Access MDB at exactly the same speed as anyone physically logged into the server. With Citrix, you'll only need 20-32kb of bandwidth for most users.

Users working over the same database crash it. It seems that when users send requests in the same time, the DB crash (it can be fixed, but that's annoying). It doesn't always happen, but when you have more than 10 users, this increases the odds.

So the short term solution was Terminal Server. It worked great and speed was fine, until in some days something happened in the Windows Server that slowed it down (some kind of caching or somewhat), so the illiterate technician just said that Windows Server is bad.

We are now (Ok, I left) reckoning on an advanced/new Web or Desktop platform. They are aiming to finish a part in the software this year. Will see what they do ;)