there is no hard and fast rule as to where Access hits problems. and in reality its usually not Access that has the problems but the underlying storage engine, which is called JET.
JET is a file server orientated mechanism and isn't clever when you have large number sof concurrent users.
there are things that you can do to circumvent this problem
design the application using unbound controls / recodsets ( a lot more code to be handwritten, you can't use most of the whizzy designers)
use another data storage mechanism such as a client server db, pick anyone you like from MySQL, SQL Server, DB2, Oracle whoever. keep the front end in Access. however you still have to code much of the glue logic between the user interface and the data. if you revert to the Access bound controls then you have the worst of both worlds, the extra load on the servers and the extra load on the local PC + Network. if you want to go down the client / server back end then rund, odnt' walk to your local geek bookshop and buy the Access developers handbook
the precise number where palin vanilla Access craps out depedns entirely on the the number of users, the way the app was written and the hardware its running on. I doubt you will get a satisfactory applciation using JET with 100+ concurrent users doing data entry. if ts 15..30 at any one time then you may be OK, mebbe higher mebbe lower.. the complexity of the table design is also going to be an issue. the more complex the table design the more likely it will bring a JET db to its knees (complex joins can crucify JET)
JET also is not happy runnign over VPN's. its will work OK on most modern networks but a VPN or remote connection is a recipie for problems.
bear in mind the JET sends chunks of data to the client, which decides what it needs from that data, whereas a server application will ask the server for the data it needs and only that data is sent. meaning a server db will have a significantly lower impact on network resources than a file server db.
you can split an Access JET db into two components., the back end (contains the data), the front end contains the user interface (forms, reports, most queries). ideally each user should have their own local copy of the front end. theres stuff in the code bank on this forum to handle deploying local front ends to remote desktops
I knew of one app which is multi thousand concurrent users, with a high transaction volume that uses an Access front end, however the back end is a client server, used to be DB2 what it is now I haven't got a clue.
what you could do is consider a web based interface such as ASP.NET, PHP, Ruby / god knows what. or a traditional language such as C, C++,
VB, .NET, JAVA et al