467,169 Members | 946 Online
Bytes | Developer Community
Ask Question

Home New Posts Topics Members FAQ

Post your question to a community of 467,169 developers. It's quick & easy.

MS Access Security Troubleshooting Guide

Existing Access Database Troubleshooting

I am new to access database and inherited an access application and
all users who were previously able to use this access file
simulataneously are now locked out exclusively . Some have not been
able to get on at all. Obviously, this is the problem, and as far as I
know, no changes have been made to access backend or front end. I have
no historical data as to whether or not the access db was secured
previously,..)

This access db is on a network share, and i have no knowledge if it's
verifying against a .mdw file on the network or on a computer
somewhere on a network. How would one determine where the access
database looks to to verify if a users are in a certain workgroup?
I've gone through most of the menu options on the access database and
couldn't find one that would show me where it references for it's
workgroup information model it uses.

If I were to recreate a new workgroup information file with this
accesss dataabase, should I be concerned about overriding any other
configuration that access may reference from a previously created file
(if one existed, and if somehow, it's referencing an existing file..?
or would this corrupt the access database.. ?)

I have downloaded the FAQ Security Access and reading through it to
understand what I need to do to recreate a workgroup file. However, I
do not know what to anticipate breaking if I recreated one, ... and
just wanted to see if any thoughts could be shared on this.

Any guidance as to how to troubleshoot an application on a network
share would be appreciated.

Nov 1 '07 #1
  • viewed: 2164
Share:
2 Replies
siewong wrote:
Existing Access Database Troubleshooting

I am new to access database and inherited an access application and
all users who were previously able to use this access file
simulataneously are now locked out exclusively. Some have not been
able to get on at all. Obviously, this is the problem, and as far as I
know, no changes have been made to access backend or front end. I have
no historical data as to whether or not the access db was secured
previously,..)
Could you describe the situation a bit more? What do you mean, locked
out exclusively? Is there an error message displayed? What is the
error number or description?

It sounds like some can get in and others can't. What's the difference
between the two? Have you looked at the desktop icon on the machines
that work and those that don't?

>
This access db is on a network share, and i have no knowledge if it's
verifying against a .mdw file on the network or on a computer
somewhere on a network. How would one determine where the access
database looks to to verify if a users are in a certain workgroup?
I've gone through most of the menu options on the access database and
couldn't find one that would show me where it references for it's
workgroup information model it uses.

If I were to recreate a new workgroup information file with this
accesss dataabase, should I be concerned about overriding any other
configuration that access may reference from a previously created file
(if one existed, and if somehow, it's referencing an existing file..?
or would this corrupt the access database.. ?)

I have downloaded the FAQ Security Access and reading through it to
understand what I need to do to recreate a workgroup file. However, I
do not know what to anticipate breaking if I recreated one, ... and
just wanted to see if any thoughts could be shared on this.

Any guidance as to how to troubleshoot an application on a network
share would be appreciated.
Nov 2 '07 #2
"siewong" <wo*****@gmail.comwrote in message
news:11*********************@57g2000hsv.googlegrou ps.com...
Existing Access Database Troubleshooting

This access db is on a network share, and i have no knowledge if it's
verifying against a .mdw file on the network or on a computer
somewhere on a network.
If you can open the file directly from an explorer window then either:

the file has not been secured correctly

or

you are joined to the custom workgroup.

The latter is not recommended, rather you (and your users) should switch to
custom workgroups on a session-by-session basis.
How would one determine where the access
database looks to to verify if a users are in a certain workgroup?
If users are joined to the default "system.mdw" workgroup then the would
need a shortcut with a valid "/wrkgrp" switch to gain access to the file.
I've gone through most of the menu options on the access database and
couldn't find one that would show me where it references for it's
workgroup information model it uses.
No, you won't find it there. The developer should have this information,
not much help to you I know.
>
If I were to recreate a new workgroup information file with this
accesss dataabase, should I be concerned about overriding any other
configuration that access may reference from a previously created file
(if one existed, and if somehow, it's referencing an existing file..?
or would this corrupt the access database.. ?)
Access will only "reference" the workgroup file you tell it to. By default
this is "system.mdw". You join other workgroups either using the workgroup
admin menu option or by using a shortcut.
>
I have downloaded the FAQ Security Access and reading through it to
understand what I need to do to recreate a workgroup file.
You can only recreate a workgroup file if you have *exactly* the same
information that was used to create the original. It wouldn't be much in
the way of security if you could easily recreate workgroup files with
minimal information.

There's a security example on my website that might help you understand the
concept (in addition to the FAQ).

HTH - Keith.
www.keithwilby.com

Nov 2 '07 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

5 posts views Thread by Norsoft | last post: by
7 posts views Thread by Visitor No 3 | last post: by
12 posts views Thread by Dr. Edmund M. Hayes | last post: by
8 posts views Thread by =?Utf-8?B?TWFuanJlZSBHYXJn?= | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.