Multi-user isn't necessarily "distributed" since using a Jet 4.0 MDB only requires a file share. All processing is still done on the users' machines. "Access" is only one client of Jet, and Jet 4.0 has been part of Windows for a long time now. Don't conflate the two. You can create, query, update, replicate, and do almost everything to a Jet database without Access installed.


Whether distributed or not, concurrency control is your major issue. With a Jet database you may want to set record-level locking, but in any case careful query design should be used to minimize locking. There are also two levels of transaction semantics you can use, at the ADO level and the SQL level.

Note that when you use a multi-user database you must program for concurrency no matter what the underlying database is and how you handle updates. A "connected" model means dealing with lock conflicts, a "disconnected" model means dealing with failed updates passed back to you. In low volume cases you can often rely on default retries to resolve many conflicts.

But think of the case where User A sees that 1 Wacky Widget is available, then User B sees it, and then they both try to "buy" it. The first one in gets it, and the second must be shown that their "purchase" failed.


Whether there is any processing distributed off the client PCs or not is probably not important for you - unless that's what your demonstration is intended to show! If it isn't required then a Jet database is as good as any for demo purposes. If it is then even using something like SQL Server may be an inadequate demonstration, and perhaps you need middle-tier code to truly demonstrate distributed processing.


No, you don't need a browser-based application. And no, updating is a normal part of the interaction so you would not limit it to admins or it wouldn't do much. That doesn't mean there won't be some tables or fields only admins update though. It depends on your application.