Question : High Concurrent User Count - Best Practices?

I have a database that maintains about 3500 - 5000 active records, with basic maintenance (decompile/compact/repair & archive) run daily.  It has 30-40 concurrent users.  All users have to update records, though none delete or add records.  The users do not ever overlap, so they do not access a record that is in use by someone else, but we're at the point where the BE gets corrupted a few times a day now.

There is a main data table in the back end on the server, with front end MDE's distributed to the agents.  There is also an import database that runs VBA code to update the data table hourly with new records from an IBM-3278 terminal interface via screen scraping.

What I'm looking for are a list of best practices (other then not exceeding 8 users), tips or tricks that will minimize corruptions.  

Answer : High Concurrent User Count - Best Practices?

I have to admit - there's something strangely appealing about your situation.  In an almost massochistic way - the thought of the absolute impossibility of moving to a server RDBMS but the requirement to support 30-40 users in a reliable fashion with a Jet BE.  
It would be fun assuming you were given the leeway to get it wrong a few times (if folks are going to lay down conditions then they need to accept consequences while the constrained perform their tests :-)

Fundamantally - it should be doable.  But almost impossible to remove the chances of corruption.
All you can do is minimise the likelihood of it.
Of everything you described - the one thing that stood out to me was:
"an import database that runs VBA code to update the data table hourly with new records "
It only appends records - or it performs updates too, just as the users are doing?

30-40 concurrent users and a mass update or rows really is pushing things.

Obviously - how sound is your structure.  To support more users - you need that much better and efficient a data structure.
Small tables - large numbers of records.  (3500 - 5000 ain't a whole lot really).
Good and appropriate index use? (Lots of indexes will harm your update time and therefore concurrency.  Reading shouldn't be corrupting your database).
Are you implementing row level locking?  Table could yield better results ironically.
Have you considered padding your records to fill data pages to simulate row level locking?
Going unbound could help with that (Scott will be able to help you all you need in discussing that if memory serves he's a big fan of unbound Access apps).

WIthout seeing the application it's hard to offer definitive advice.
As I say - with it in hand on the network in use - it could be interesting to see.
Remotely it's hard to offer any nugget of inspiration though if that's what you're after.
Consider this old similar situation of Steve's a while back going from here http://www.experts-exchange.com/Microsoft/Development/MS_Access/Q_21755013.html through http://www.experts-exchange.com/Microsoft/Development/MS_Access/Q_22393835.html to http://www.experts-exchange.com/Microsoft/Development/MS_Access/Q_22433474.html