MS Access via mapped drive

[Dusty]

Hi there
I am currently trying to install a new ms access based data base program
onto my server to be accessed via mapped drives. I dont currently have access
instaled onto my server as i dont have the correct licenses to allow it to be
accessable via terminal services, although i do have it installed onto all
computers accessing the mapped drive. The only problem i seem to be having is
that when i try to open up the data base microsoft keeps telling me i dont
have the correct permissions. I have tried everything including setting the
security to access by everyone and tried multiple times to open it using my
administrator login without any luck.

Any suggestions on how to repair this security issue?

 

[Douglas J. Steele]

When you say "setting the security to access by everyone", what exactly did
you do? Did you check the permissions for both the folder and for the share?

Users require the ability to create files in the folder where the database
exists: this is to enable the creation of the locking file (.ldb) by the
first user to connect to the back-end. Subsequent users need the ability to
update that locking file (I've heard of cases where the permissions allow
user A to create the ldb file, but does not allow users to update ldb files
which they didn't create)

 

[Arvin Meyer [MVP]]

In addition to Doug's post:

The users need the ability to Delete the LDB file as they leave the
database. The last user leaving is the one that deletes the file. IOW, all
users need all permissions with the exception of FullControl (because they
do not need to take ownership, only domain admins need FullControl).

 

[Douglas J. Steele]

Hate to argue, Arvin, but (as David Fenton likes to keep pointing out), it's
not mandatory that they have Delete permission, so I don't think not having
Delete would raise an error message.

Of course, if they don't have it, you'll run into issues getting exclusive
access to the database for operations such as Compacting.

The other thing we didn't clarify with Dusty, though, is whether the
application is split into a front-end (containing the queries, forms,
reports, macros and modules), linked to a back-end (containing the tables
and relationships). If it isn't, it should be. Only the back-end would be on
the server. Each user should have his/her own copy of the front-end, ideally
on his/her hard drive.

--
Doug Steele, Microsoft Access MVP

(no e-mails, please!)

 

[David W. Fenton]

Hate to argue, Arvin, but (as David Fenton likes to keep pointing
out), it's not mandatory that they have Delete permission, so I
don't think not having Delete would raise an error message.

Of course, if they don't have it, you'll run into issues getting
exclusive access to the database for operations such as
Compacting.

I always include in my posts correcting those who claim that DELETE
is required the point that you can give delete permission to the
people who you want to have permission to compact the database.

Basically, there are two classes of users of your database, regular
users (who don't get DELETE permission on the folder contents) and
admin users (who get full control). Any time an admin user is the
last one out of the database, the LDB file will be deleted. And the
admin user can delete the LDB file when needed to do a compact.

The reason for removing DELETE permission on the folder is so that
users can't accidentally delete your data file. This can also be
accomplished by applying the DENY DELETE to the MDB file itself, but
that won't survive a compact (since the compact creates an entirely
new file that inherits the default permissions of the folder).

I have been running my clients' apps without DELETE permission for
normal users for over 10 years. There have been no problems caused
by this at all.

 

[Arvin Meyer [MVP]]

If the last person out doesn't have delete permissions the and LDB has a
lock, I have had to reboot a server when this happens because it won't let
anyone do a compact until the file is closed. Rebooting a server during
production hours brings down the ire of management, so I must work overtime
to avoid that happening. I don't like that, so regardless of David Fenton's
declarations, I expect that everyone with permissions to use the database
has all permissions on the folder with the exception of FullControl.

That said, you bring up a good point about split databases. If they aren't
they need to be.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com

 

[Arvin Meyer [MVP]]

I have been running my clients' apps without DELETE permission for
normal users for over 10 years. There have been no problems caused
by this at all.

I stick by my answer. Reap my reply to Doug.

 

[David W. Fenton]

If the last person out doesn't have delete permissions the and LDB
has a lock, I have had to reboot a server when this happens
because it won't let anyone do a compact until the file is closed.

Er, what? Can't you just close the file handle? I.e., through the
computer management console, view the open files/shares and force
close the lock.

That said, I've never seen the failure of the deletion of the LDB
file to also hold a lock on the file. I've only seen that when
there's been an improper termination of Access.

Rebooting a server during
production hours brings down the ire of management, so I must work
overtime to avoid that happening. I don't like that, so regardless
of David Fenton's declarations, I expect that everyone with
permissions to use the database has all permissions on the folder
with the exception of FullControl.

If the lock is being held on the LDB file, then there's a problem
somewhere that doesn't have a thing to do with delete permissions on
the relevant folder.

 

[Arvin Meyer [MVP]]

Er, what? Can't you just close the file handle? I.e., through the
computer management console, view the open files/shares and force
close the lock.

No, didn't work both times that it happened

That said, I've never seen the failure of the deletion of the LDB
file to also hold a lock on the file. I've only seen that when
there's been an improper termination of Access.

No way to really tell since both persons swore that they'd closed out
properly. Both times that it happened was some time ago, I believe on an NT
4 server the first time and a Win 2000 server the second. Two different
people, but both from the same department of the same company using the same
front-end on each of their machines. The instances happened about 8 or 10
months apart.

 

[David W. Fenton]

No, didn't work both times that it happened

Very bizarrely, today I was at a client's, working on my laptop
using Remote Desktop to work on their Access app, and could not
compact without getting an error about "the db is not open
exclusively." I checked open files, and nobody else had it open, and
I was the only session open on the Terminal Server. I then went to
Windows Explorer and was able to simply delete the LDB file. But it
still wouldn't work, giving the same error. So, I then deleted the
LDB file again and tried renaming the MDB file, which succeeded, and
then I could compact it.

I checked the permissions on the share and on the underlying folder
and all authenticated users had full control, so I have no idea what
was happening.

If there was file system replication going on, I'd think it was
related to that, but that's not applicable, so I'm at a loss.

And it's definitely not the DELETE permissions, either.

No way to really tell since both persons swore that they'd closed
out properly. Both times that it happened was some time ago, I
believe on an NT 4 server the first time and a Win 2000 server the
second. Two different people, but both from the same department of
the same company using the same front-end on each of their
machines. The instances happened about 8 or 10 months apart.

This happened to me on Win2K Server. I work in this environment very
frequently, though this is the first time I've done it since the
clients moved into new offices the day I was moving (Jan. 30th). But
the server and network infrastructure were moved without any
alterations whatsoever, so that couldn't possibly have an effect
that I can think of.

I'm stumped on this one, since I had full permissions and nobody had
the file open.

Maybe I need to install Process Explorer and see if something has it
open in the background, or if an Access instance is not closing out
properly.