Link to a RW database from a RO database?

[Leif]

For security purposes I would like to create an Access database in a
directory defined as read-only for a certain class of users. However, I need
to programmatically record their access to the database when they open the
database.

I was thinking a possible solution is to provide a table link to another
access database for which they have read/write access. When they log in my
autoexec routine could write out some information to this second database
that is read/write.

Does Access allow you to write to a linked table from a read-only database?

Regards,
Leif

 

['69 Camaro]

Hi, Leif.

Does Access allow you to write to a linked table from a read-only database?

Yes. Just make sure that the table link is created before the file is made
read-only.

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
http://www.Access.QBuilt.com/html/expert_contributors2.html for contact info.

 

[Leif]

Actually I don't know if it makes a difference, but the directory will be
made read only for certain users. I'll still have full read/write access.

If I wanted to use Access security I would need to make the directory
read/write to allow for the lock file creation and deletion, right? In that
case, could I make the database file itself read-only (for certain users
only) inside the read/write directory? We are using Windows NT servers.
Thanks.

 

['69 Camaro]

Hi, Leif.

Actually I don't know if it makes a difference, but the directory will be
made read only for certain users. I'll still have full read/write access.

It matters -- if you intend to have the database file open concurrently.
It's better to give restricted users "Full control" permissions, but ensure
that they only open the Access database file with a shortcut that includes
the /ro command-line switch.

could I make the database file itself read-only (for certain users
only) inside the read/write directory? We are using Windows NT servers.

Yes, but the problem with this is that when the file is compacted, depending
upon the user's operating system and the version of Access used, the file
could get a totally new set of file permissions, because it's a brand new
file created in that directory as a result of the compaction. And even if
you had the correct combination of operating system and Access version,
there's no guarantee that the next OS or version of Access -- or patch --
installed on any of the users' computers is going to allow you to continue to
dodge the bullet.

For a list of the methods to use when there are restricted users (and a list
of what happens when you don't use a correct method), please see the
following Web page for a link to the article, "Multiuser Databases":

http://www.Access.QBuilt.com/html/Articles.html

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
http://www.Access.QBuilt.com/html/expert_contributors2.html for contact info.

 

[Leif]

Hi 69,

I've read your website posting. My major concern is the ability of a user
to delete the mdb, either by accident or on purpose.

I know you recommend full permissions. However, I've done testing giving
the non-admin user all permissions except delete. That seems to work. The
lock file stays behind when that user exits, but I've not found that it
causes problems. Is there a better way to handle the concern? We do
backups, but it can take IT days to get a file back.

Regards,
Leif

 

[Joan Wild]

You could also hide the folder where the backend is

\\servername\share$ rather than \\servername\share

 

[Leif]

Hi Joan,

Thanks for the suggestion. Is there something magic with a "$" name, or do
you mean just a different directory name? I guess if they had their explorer
setting to set to see hidden directories/files they would still see it, but
may not make the connection with the front end, right?

Regards,
Leif

 

[Joan Wild]

Putting the $ at the end of the name hides it in Windows Explorer. They
won't be able to see it even if showing hidden directories/files. They
would need to know the directory name with the $ (and type it in the address
bar) in order to see it. So don't tell them.

 

[Leif]

Does it only work at the share level? I tried it with a subdirectory of my
main directory, and it is visible. I would just try it, but I work for a big
company and the IT org. takes about a week to act on a request for a new
directory on a server. Plus, I'm not positive they will let me create a
directory that high up in the hierarchy.

Regards,
Leif

 

[Joan Wild]

I believe so. A short path also improves performance.

 

[david epsom dot com dot au]

The persistent lock file has three effects:

1) It prevents access from 'cleaning up' hanging
lock information after everyone has left.
(admins used to have to do this if they had
database corruption or network failures)

2) It prevents a stupid optimisation that
no one uses: you can't create and use 'exclusive'
links.

3) It makes connecting faster (but might possibly
in some circumstances make disconnecting slower).

But your users still have modify permission: so
if they are malicious, they can do just as much
damage as if they had delete permissions.

(david)

 

['69 Camaro]

Hi, Leif.

I've read your website posting. My major concern is the ability of a user
to delete the mdb, either by accident or on purpose.

Say your organization takes the approach listed as #4 in the article. (BTW,
the hidden share mentioned in this method in this article is the
\\servername\sharedDir$ that you've been discussing with Joan Wild
elsethread.) The hidden share can't be accessed by mapping a new drive, and
the user can't open "My Network Places" on his workstation. Given these
shackles, what steps do you believe your users would take to deliberately
delete this file? Remember that they can't see the directory or file from
within Windows Explorer. Most Windows computer users can't delete
directories and files, even accidentally, unless they can see them within a
GUI and can use their mouse to select the name of the directory or file.

I know you recommend full permissions. However, I've done testing giving
the non-admin user all permissions except delete. That seems to work.
The
lock file stays behind when that user exits, but I've not found that it
causes problems.

Occasionally, something goes wrong and everyone gets locked out of the
database:

"The database has been placed in a state by user 'username' on machine
'machinename' that prevents it from being opened or locked."

These are the times when the problem may be fixed by deleting the LDB file,
which removes the current exclusive lock. If no one has delete permissions
on this directory then the lock remains. You'll need to contact your
Windows network administrator to delete the LDB file for you. As you
mentioned, this is not quite the immediate response you need. Users could
be locked out of your database for days, waiting for IT to get back to you.
Is this acceptable?

We do
backups, but it can take IT days to get a file back.

This is a management problem. It needs to be addressed by your
organization. In the meantime, I suggest an agreed upon time when everyone
closes the database so that one of you can make a daily (or noontime, or
hourly, et cetera) backup of the file and store it in a safe place on the
network, just in case the current database file needs to be restored and IT
is MIA.

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
http://www.Access.QBuilt.com/html/expert_contributors2.html for contact
info.