Networking unsecure database

  • Thread starter Thread starter Guest
  • Start date Start date
G

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?
 
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
 
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.
 
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.
 
Immanuel Sibero said:
All users must have full access
rights to the folder in which the database resides.
Click to expand...

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
 
Keith Wilby said:
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?
Click to expand...

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.
 
Douglas J. Steele said:
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.
Click to expand...

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.
 
Keith Wilby said:
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?
Click to expand...

That's right.
 
Douglas J. Steele said:
That's right.
Click to expand...

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.
 
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
 
Immanuel Sibero said:
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?
Click to expand...

Yes, delete permissions are required for compact.
 
Immanuel said:
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?
Click to expand...

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.
 
Back
Top