MS Access is weird.  We run into this all the time on our network where we
want some users to have full rights to a database, and others have only read
rights.  Turns out if the read-only people connect while a full-rights
person is connected they get "blocked"(!)  See, no matter what your rights
to the .mdb, you have to have full-rights to the .ldb (maybe even create it,
if it is not present) in order for Access to work properly.  (Access suxs
for this, but wacha goin do).

The solution for multiple users on a network share is to place the .mdb file
in a folder.  Permission the folder for with full-rights for everbody.  Then
restricts rights to the .mdb file itself for the read-only folks.  This
allows everybody to create/write the .ldb file.  A nasty side effect is that
the read-only folks can create/write to any other files in the subfolder.
You cannot just permission the .ldb explicitly, because sometimes it get
deleted.

(There is a KB article on the above, I'll try and track it down._

OK. How does this apply to a web app...

If the .mdb was on the same server, you would just give the local ASPNET
user full rights to the folder that contains the .mdb.  There, problem
solved. :)

Since you database is on a different server you have to do more. This is
what I do all time; "Pass-through authentication".

The steps:
#1. Change the password for your ASPNET user on the webserver. (If will give
dire warnings, but just do it).  Set it to something secret.
#2. Open machine.config on webserver.  Fine the processModel section.
Change password from "autogenerate" to your new password.

Run iisreset to restart webserver (or just reboot webser).  (If you ever
apply .dotnet SP1 or a future SP; it will reset the ASPNET password back to
some unknown, and things will break - cause it won't match what the
machine.config says.  Just reset it again, and double check the account
didn't get lock out.)

Now ASP.NET is running on your webserver with the still limited user
account; ASPNET, but now with a known password. (that is the key to making
this work)

#3. On network share server, create a local account named "ASPNET".  Make
password the same as above.
#4. Permission the folder containing your .mdb file on this server, so that
this local account has read-write access to the entire folder(!).

You could have made a domain account, and changed your webserver to run
using it instead. But then you would have to assign that domain account the
same rights as the local ASPNET user on the webserver for things to work
correctly.  (That is tricky to do, and not necessary using pass-through).
There are KB on how to do this, but doesn't seem worth the hassel to me.

Added bonus: this method works also if you ever need to connect to SQL
Server running on another server than your webserver.

Let me know what you need cleared up. I'm typing pretty fast. :)

Greg

I guess it depends on how big your database is? Its only one option.....and
may be entirely unsuitable for your needs.

You are of course correct - in that it "can" be shared. This was my chain of
thought:

Unless you open it in shared mode at connection time its pretty much a
single user database, as once its opened by anyone in exclusive mode its
locked for access to everyone else until that lock is cleared.  .Also, if
you have any access client opening any tables for any form of schema
editing, you will by default lock it to that user alone and render the
database exclusively locked until that user releases the system - forcing
single use.  This is a problem with shared Access databases, as you cant
compact or repair a shared DB file if the LDB claims its shared and you
could end up with a corrupted DB due to sharing problems and invalid record
locking.  All round, Access is not the ideal choice for a shared
database.....

Yes, but the OP is talking about sharing the same Access database between
internal users over a network and external users over the web.

OK - I was under the impression that there was some intentional internal
limit to the number of concurrent connections.

Yes indeed - good advice, and not just for Access... :-)