Attached Tables "Already in Use"

  • Thread starter Thread starter BarryC
  • Start date Start date
B

BarryC

I have two applications sharing an .MDB. Both are Access2000
applications that attach the datastore's tables. When one is open, the
other errors out with "Could not use 'Foo.mdb. File already in use".
The application that gives this error is in another directory. The user
of the erroring application only has Read priviledges on the directory
where the datastore MDB resides. Due to SarbOx, I believe that is the
highest permission level available to that user.

What can I do about this?
 
Hi Barry,

As I understand it, for normal, shared use of a .mdb back end all users
need read, write and delete permissions on the folder so that each
user's instance of Access can create, modify or delete the .ldb file.

If a user has only Read permission on the folder, they can open the .mdb
file read-only, provided it isn't already in use by a user with "normal"
permissions.

The only work-round I can think of is this, and I'm not certain that it
would work: Would your regulatory requirements be met if the users had
RWD permissions on the folder, but only R permission on the .mdb file
itself?

But don't take my word for it. I suggest that you ask in the
microsoft.public.access.security newsgroup: the gurus there may have a
better idea. Otherwise, I suspect you may have to move your back end to
SQL Server to get the combination of security and flexibility you need.
 
Not able to see the original question, so tacking on here. I don't know
what SarbOx is, but in a multiuser setting, users need the
read/write/create/delete permissions on the folder in order to be able to
create the associated ldb file, as John said.

As long as users need only read permission on the mdb file, you could set
the permission on that file, however when you compact that database you'll
need to reset the permission, since the resulting mdb will inherit
permissions from the folder.

If you're concerned that the user might delete the file, you could always
put the backend in a hidden folder.
\\server\share$ rather than \\server\share
 
Thanks, Joan. I assume that SarbOx stands for Sarbanes Oxley (sp.?). If
so, it's a reference to compliance with regulations affecting US
financial institutions, regulations which weren't written with Jet
security in mind<g>.
 
Yes, I mean Sarbanes-Oxley.
From what I understand, the law boils down to only giving Write access
Click to expand...
to those who really need it. It supposed to prevent book-cooking and
create an unbroken chain of accountability all the way up to the CEO.
 
Back
Top