"No Locks" does actually mean no locks. The problem with that option is that
if the edited record has changed in any way since the current user last read
the data, that user's update will be rejected. But it should not cause any
lockups. That approach is also called "optimistic concurrency", as in "let's
hope there aren't any conflicts and then the users won't be presented with
an ugly message that their changes cannot be saved". Setting the form lock
property to edited record will actually lock the record when a user makes
the first change to that record. No other user will be able to edit that
record until the first user either saves their changes or cancels the edit.
Depending on the application's data access patterns, setting the lock
property to edited record is probably a better choice for that many users.
When you say 135 users in 4 hours, how many of those users have the
application open simulataneously? Access has a firm upper limit of 255
concurrent users, but if any code in the application, or any other
application, opens additional database connections, you could be reaching
those limits. I've never used an Access backend for more than about 50
simultaneous users, and I don't remember seeing people report more than 100
simultaneous users. The upper limits are more likely to be successful if
most of the users are just reading data, not writing. Any kind of network
issue for any connected user can lockup the Access database, perhaps leading
to the kind of symptom you're seeing. Are any of the users connecting over a
WAN or a wireless connection? Either of those conditions makes lockups so
much more likely that most people recommend against using either with an
Access backend. Is the backend database on a server? I think all recent
client OS's are limited to 10 simultaneous network connections, which could
also produce the symptoms you're seeing.
