Access Security Problem

[mcp6453]

Let me first apologize for the lack of detail in this question as I do not know
much about Access, and I am writing this post from memory. An XP computer is
connected to an NT Server acting as a file server only. The XP computer does not
join the domain. The file server has a custom Access application on it. Before
the XP computer was rebuilt, the user could browse to the folder on the server,
double click on the .mdb file, and Access would open and function as expected.

Now, after reinstalling Windows, when she double clicks on the file, she gets a
pop up window saying that there is a security problem, that the file cannot be
opened, and that she needs to move the file to the local disk. The problem is
that the application is hard-coded to read files on the remote disk. Plus, this
exact setup worked before the rebuild.

Access is prompting to set up a workgroup. Is setting up an Access workgroup
part of the solution? Thanks for the assistance. Access is Version 2002, I believe.

 

[GeoffG]

If this is a multi-user application (which it sounds like it is)
and, if more than one user is opening the same mdb file, then
your original setup wasn't ideal. The database should be split
into a front-end (each user would run their own copy of the
front-end) and a backend (one copy only on the server containing
the tables, i.e. the data). The front-end would have linked
tables, linked to the backend. This arrangement has a number of
advantages, whereas your apparent setup may be prone to
corruption.

I think your original setup probably worked because it used a
shortcut to start Access. The shortcut's command line could have
started Access and made Access aware of which workgroup (mdw)
file to use and which mdb file to load from the server. See
Access Command Line in help. Alternatively, Access had been
configured to use the same mdw file for all Access databases. It
seems your task is to find the mdw file and make it available
when running the mdb file if you want to create the old setup,
but, as I say, that may be an unwise temporary solution. Make
sure the database is backed up every day!

Geoff

 

[mcp6453]

As I understand it, the data files were stored on the server to be accessed from
several computers, each running Access. I am positive that Access was not run
from the server. Now, only one computer needs access to the files. In fact, we
want to move those files to the one computer and get rid of the server. It is
old and unnecessary.

It seems like the developer may need to configure the application to run on the
local computer. It's beyond my knowledge base to know how to do that. After I do
some investigation based on your comments, I may post back. Thanks for the
explanation.

 

[mcp6453]

Are you sure it's Access prompting, not Windows? This isn't normal. What
are the exact words of the message?

Chris

When I browse to the shared folder on the server and click on the mdb file, the
first prompt is "Open File - Security Warning, Do you want to open this file?"
which is a Windows warning. I click Open.

Access opens, and then this message is displayed:

Microsoft Access cannot open this file.
This file is located outside your intranet or on an untrusted site. Microsoft
Access ill not open the file due to potential security problems. To open the
file, copy it to your machine or an accessible network location.

There is no security concern in opening the file. The shared folder is mapped as
Drive F, just as it was on the computer before the rebuild. Copying the file to
the local drive does not solve the problem because there appears to be some
pathing hard coded into the application.

 

[mcp6453]

I'm the one who rebuilt the PC, as I have done 1000 (literally) others, and
never before have I had to do this step. I did what you suggest, and the file
opened without warnings. Are there any other aspects of this configuration that
I need to be aware of?

Access does have a workgroup setup function in it. I just didn't get that prompt
this time When I get back to that computer, I can find it, if you want. I had
never seen it before, either.

 

[mcp6453]

Our objective is to get rid of the server and use a second drive in a work
station as a shared drive, backed up nightly. There is less than 2GB of actual
data on the server.

Where do the scripts come that you mention below? I do everything by hand.

When I rebuild a pc, I run scripts to rename the pc, set up dhcp for
automatically assigning the ip address, trust the network, etc. Apparently
your script for trusting the network didn't run or wasn't included with the
rest of the install scripts. I can't think of anything else you need to
configure for Access 2002 on Windows XP, so your work should be done there.
As for the nt box, if you replace it with a Windows 2000 server or 2003
server, there's a file lock issue that can corrupt mdb files. Make sure file
locking is off.

Access doesn't prompt for a workgroup unless you're messing with the security
wizard. I don't advise doing that unless you know what you're doing or you
want to accidentally lock yourself out of the db.

Chris

I'm the one who rebuilt the PC, as I have done 1000 (literally) others, and
never before have I had to do this step. I did what you suggest, and the file
opened without warnings. Are there any other aspects of this configuration that
I need to be aware of?

Access does have a workgroup setup function in it. I just didn't get that prompt
this time When I get back to that computer, I can find it, if you want. I had
never seen it before, either.

Access *isn't* prompting to set up a workgroup. It's telling the user drive
f isn't trusted on the intranet (like it was before the rebuild). Whoever

[quoted text clipped - 27 lines]

the local drive does not solve the problem because there appears to be some
pathing hard coded into the application.

 

[GeoffG]

Your first post:

The user could browse to the folder on the server, double click
on the .mdb file, and Access would open and function as
expected.

Sorry I didn't read the above carefully.
Obviously, a shortcut wasn't how the database started!

Your first post:

Access is prompting to set up a workgroup. Is setting up an
Access workgroup part of the solution?

I guess you figured the above made me think the developer had
implemented user-level security. That would have needed a custom
workgroup (mdw) file for logging into the database.

Interesting to see it's a permissions issue.
And also to see Chris's solution using Internet Explorer.

Your first post:

The problem is that the application is
hard-coded to read files on the remote disk.

Do you know what files?

1. If you had a backend database, the hard-coded paths would be
in the linked tables pointing to the the backend mdb file. They
could be fixed relatively easily after moving the backend
database.

2. If the paths are in, say, some VBA code, then I think you're
probably out of luck: the database developer will need to fix
this (unless you have skills in this area).

Your last post:

Where do the scripts come that you mention below? I do
everything by hand.

I'm out of my depth here, but you may find the following book
helpful:

"Ungrading and Repairing Microsoft Windows"
by Scott Mueller and Brian Knittel

This seems to be a big subject!

Geoff