Networking unsecure database

[Guest]

I have a standalone database that can be opened once from a shortcut on the
desktop. With it opened anyone else attempting to use the database shortcut
cannot open it, no error message, just hourglass then it dies. It cannoe even
be opened by doubleclicking the file itself.

If the second user opens access program then the database can be opened
without issue by using file/open/databasename.mdb.

I'm told this used to work just fine and the suggestion has been made
already to split the database but that idea has been rejected and is not an
option for me here.

SP2 was recently installed on these PCs and it's probably got something to
do with this. What can I do to make the shortcut work again for multiple
users?

 

[Immanuel Sibero]

Hi,

Splitting the database is highly recommended. It should be a requirement for
multi users, period. Another area where multi user access issues frequently
come up is user rights and priviliges. All users must have full access
rights to the folder in which the database resides.

One thing I do when I'm faced with something like this (READ: when I have no
clue) is to try to reproduce the problem under different environment. This
may give you a clue where the problem is or where to strart looking.

Is this behavior true for all Access database? Have you created a brandnew
blank database and tried to duplicate this behavior? Do you have another
machine with different operating systems (i.e. Win2000, 98, etc..) to see if
the behavior is the same?


HTH,
Immanuel Sibero

 

[Guest]

What I did to test was place a copy of this database in my user drive on the
network and try the same thing. This reproduced the problem of course. I have
all available rights since I'm one of three admins here. The same issue
occurs. I understand the importance of splitting but am not being given that
option unfortunately.

I'll create a fresh database next and see what happens.

 

[Lynn Trapp]

I'm really puzzled why you are not being given the option of splitting the
database. All that does is create a separate .mdb file that is then placed
on each user's machine.

 

[Keith Wilby]

All users must have full access
rights to the folder in which the database resides.

Are you referring to the NTFS file permissions? For NTFS, the user needs
only RWX permissions - this allows them to write the ldb file and to modify
the data in the mdb BE whilst denying access to delete files. Or am I
missing something?

Regards,
Keith.
www.keithwilby.com

 

[Douglas J. Steele]

Are you referring to the NTFS file permissions? For NTFS, the user needs
only RWX permissions - this allows them to write the ldb file and to modify
the data in the mdb BE whilst denying access to delete files. Or am I
missing something?

They need Delete on the folder where the MDB exists so that they can delete
the LDB file if they're the last user to leave the database. Without that,
it becomes extremely difficult to compact the database, as Access thinks
there are users even it there aren't.

 

[Keith Wilby]

They need Delete on the folder where the MDB exists so that they can
delete the LDB file if they're the last user to leave the database.
Without that, it becomes extremely difficult to compact the database,
as Access thinks there are users even it there aren't.

I really didn't think a stray ldb was an issue since the administrator
(with Full Control permissions) can delete it before compacting.

Having re-thought my stance on this though, I suppose a more elegant way to
protect against accidental or malicious deletion of the mdb would be to
provide RWXD permissions to the folder but RWX permissions to the mdb -
would you go along with that?

Regards,
Keith.

 

[Douglas J. Steele]

I really didn't think a stray ldb was an issue since the administrator
(with Full Control permissions) can delete it before compacting.

Having re-thought my stance on this though, I suppose a more elegant way to
protect against accidental or malicious deletion of the mdb would be to
provide RWXD permissions to the folder but RWX permissions to the mdb -
would you go along with that?

That's right.

 

[Rick Brandt]

That's right.

But with every compact operation the MDB will inherit the permissions of the
folder will it not? I guess as long as you don't mind (and remember) to change
it each time.

 

[Immanuel Sibero]

Hi Rick and all,

Admittedly, I never really looked into this very closely. I have always
given Full Control to folders where Access related files reside. Would
giving only RWX to mdb be sufficient where regular users need to
occasionally compact the database? Dont they need Delete permission for a
compact operation?

Thanks
Immanuel Sibero

 

[Keith Wilby]

Would
giving only RWX to mdb be sufficient where regular users need to
occasionally compact the database? Dont they need Delete permission for a
compact operation?

Yes, delete permissions are required for compact.

 

[Douglas J. Steele]

But with every compact operation the MDB will inherit the permissions of the
folder will it not? I guess as long as you don't mind (and remember) to change
it each time.

I suppose so (although I believe you can turn that behaviour off, can't
you?)

You could always use MichKa's code from
http://www.trigeminal.com/codes.asp?ItemID=25#25

 

[John Mishefske]

Hi,

Splitting the database is highly recommended. It should be a requirement for
multi users, period. Another area where multi user access issues frequently
come up is user rights and priviliges. All users must have full access
rights to the folder in which the database resides.

One thing I do when I'm faced with something like this (READ: when I have no
clue) is to try to reproduce the problem under different environment. This
may give you a clue where the problem is or where to strart looking.

Is this behavior true for all Access database? Have you created a brandnew
blank database and tried to duplicate this behavior? Do you have another
machine with different operating systems (i.e. Win2000, 98, etc..) to see if
the behavior is the same?

Immanuel, an interesting issue to be aware of is Access 2000's unique
behavior of compacting to the defined TEMP directory (and thus
inheriting its permissions rather than the application directory). This
was fixed in A2002 but can be a sticky issue to be aware of.