Help!!

[tw]

I don't know what I did, but I skrewed something up.

This is what I think I did. I have a test database (a copy of our live
data) on my hard drive. I've been working at adding groups and users to
that table and got everything set up almost the way I wanted. I then got
sidetracked into testing how best to implement the security into the live
data. There was a copy of the database in the same folder as the live data,
and I used that one to test joining the workgroup file to see how that would
work. Once I did that, the live data also joined the workgroup file. I
think I understand why it did that on my system, but when that happened,
other users on their machines started getting permissions errors. One of
the systems that had problems didn't have wrkadmin.exe on their machine, and
I could not find a system.mdw, so I copied my system.mdw into the folder on
the network and then from my machine joined that workgroup file. But then
when I went to open the data from my machine while that user is logged in, I
can't. I think I understand why, we're both using the same login Admin and
the same workgroup file (I think). I need to set it back the way it was. I
think I need to rejoin the default access workgroup system.mdw on my
machine, but I don't want to mess things up any further.

I know I messed up, so please don't ream me...just help me fix it.

Thanks

 

[Scott McDaniel]

If you did manage to implement User Level Security, here's a link that will
show you how to "desecure" your database:

http://support.microsoft.com/default.aspx?scid=/support/access/content/secfaq.asp#_Toc493299668

Topic #34 is a good place to start ...

 

[tw]

I did the steps below that I explained. I'm not sure if USL is not set up.
I don't know if it somehow got partially set up when I did what I explained
below, but here are the symptoms right now...

Every user seems to be able to get into the database without problem with
two exceptions. Each one of those users that can get into the system show
record locking on the database file (the file that gets temporarily created
when someone has the system running). When the specific user gets in that
was having permission errors after my original mistake gets in the
system.mdw also shows record locking, indicating that that workgroup is
being used when she logs in. When I log in the same thing happens,
indicating that I am also using that system.mdw file. Everyone esle seems
to be using there own local system.mdw when they log in (however I don't
have visual confirmation) When both she and I try to log in at the same
time we can't because appearently since we are both using the same
system.mdw and both trying to log in as Admin (this is the original
system.mdw from my system that was copied to the network to try to solve the
permissions problem that the user was having because she didn't have a
system.mdw on her own machine.) we cannot because one of us is already
logged in using that user id.

I just want to know before I skrew anything else up, if I rejoing my local
system.mdw is it going to cause permission problems for the other user, and
I it is how am I going to resolve the issue of both of us being able to log
in at the same time until I am ready to actually implement the USL that I am
working right now.

I have looked at number 34 of the security document and it doesn't seem to
apply because Admin already has administrator rights.

 

[Joan Wild]

tw wrote:

Perhaps a little understanding about workgroups and permissions might help
you help us to understand. Every session of Access uses security. Out of
the box, it ships with a workgroup called system.mdw. When you start
Access, it uses this workgroup and silently logs you in as a user called
'Admin'.

This system.mdw workgroup is set as your default for all sessions. When you
implement security, the first step is to create a new workgroup file.
During this process, Access will make this new workgroup the default for all
sessions. There must always be some workgroup that is the default. The
default can be ignored only by creating a desktop shortcut that uses the
/wrkgrp switch to point to a different mdw to use *for that session* of
Access.

The workgroup file contains usernames, groups, memberships, passwords.
Permissions though, are stored *in the mdb file*. It is possible to use
many workgroup files with one database, and also many databases can use one
workgroup file.

The fact that people are able to get in using the their standard system.mdw
suggests that it isn't secure. You can determine the mdw file *in use* by
hitting Ctrl-G and typing ?dbEngine.systemDB

You should use the workgroup administrator to join your secure mdw and
remove security.

 

[tw]

Please see inline responses.

tw wrote:

Perhaps a little understanding about workgroups and permissions might help
you help us to understand. Every session of Access uses security. Out of
the box, it ships with a workgroup called system.mdw. When you start
Access, it uses this workgroup and silently logs you in as a user called
'Admin'.

I understand this...

This system.mdw workgroup is set as your default for all sessions. When
you
implement security, the first step is to create a new workgroup file.
During this process, Access will make this new workgroup the default for
all
sessions. There must always be some workgroup that is the default. The
default can be ignored only by creating a desktop shortcut that uses the
/wrkgrp switch to point to a different mdw to use *for that session* of
Access.

Then why is there no copy of system.mdw or *any* mdw on the machine in
question. the target of the shortcut to the database on that machine looks
like this
\\ServerName\ShareFolder\ProgramName.mdb which would assume the system.mdw I
would guess, but there is no system.mdw on this person's machine. That's
why I copied my system.mdw from my machine to the folder where the data was.
Now she is using that system.mdw which does make sense since it is not
explicity named in the target it takes the first one it finds which would be
in the shared folder.

The workgroup file contains usernames, groups, memberships, passwords.
Permissions though, are stored *in the mdb file*. It is possible to use
many workgroup files with one database, and also many databases can use
one
workgroup file.

I understand this as well.

The fact that people are able to get in using the their standard
system.mdw
suggests that it isn't secure. You can determine the mdw file *in use* by
hitting Ctrl-G and typing ?dbEngine.systemDB

Thanks, this is helpful.

You should use the workgroup administrator to join your secure mdw and
remove security.

This is what I thought, but didn't want to do cause further hassles to the
other user.
Thanks, I'll just do this until I'm ready to implement the security I'm
working on in the copy on my local drive. I have it all worked out. I'm in
the testing phase with all the users to make sure everything works as
expected prior to implementing.

 

[tw]

also...
If I rejoin the system.mdw on my local machine, should I delete the
system.mdw on the server machine... keeping in mind that the other machine
does not have a copy of system.mdw on it, or will that cause the problems
originally created when this all started in the first place?

 

[Joan Wild]

also...
If I rejoin the system.mdw on my local machine, should I delete the
system.mdw on the server machine... keeping in mind that the other
machine does not have a copy of system.mdw on it, or will that cause
the problems originally created when this all started in the first
place?

If that machine has Access installed, then there is a system.mdw file on it.
Your search via Start, Search may not find it if folders are hidden.
Perhaps the user you are logged in as doesn't have permission to view the
folder where the file is. Open Access on that machine and use
dbengine.systemdb to get the path of its default workgroup. Normally (but
not always) system.mdw is found in the windows system folder.

Your server should not have a system.mdw (unless this is the secure one you
created? - you should really give it a different name if so). Why don't you
rename it rather than delete it, just in case.

more inline...
It's there somewhere.

How do you know she is using this one?
The thing is that you may have tested things on a copy, but the new
workgroup became your default one. If you subsequently opened the live
database, you would be doing so using your secure.mdw, not the standard mdw
and you may have changed permissions on it.

 

[tw]

This is a windows98 system, I did do the search via start, I included all
files/folders (hidden as well) on c:\ which is the only local drive there is
no system.mdw... it is possible that somewhere on the nework in her path
there is a system.mdw, but I havn't had a chance to check that out yet.

 

[tw]

I stand corrected... the problem was not that she didn't have a system.mdw,
she had 3 of them. The problem was that she didn't have the option for
workgroup admin on the menu nor did she have wrkgadmin.exe on her system.
Also, she has the security wizard option on the menu, but when it is clicked
on, she gets a message that the wizard is not installed. I think I have
everything worked out though, since I will be using a shortcut to the .mdw
file when I implement. She doesn't need the wizard, or wrkgadmin. Thanks
for your help, when I get a chance I will re-install access on her machine
to make sure everything that should be installed is. But for now I think
I'm ok.

 

[Joan Wild]

This is a windows98 system, I did do the search via start, I included
all files/folders (hidden as well) on c:\ which is the only local
drive there is no system.mdw... it is possible that somewhere on the
nework in her path there is a system.mdw, but I havn't had a chance
to check that out yet.

Open Access on that machine and use dbengine.systemdb to get the path of its
default workgroup.

Is Access really installed on the machine, or the runtime?

 

[Joan Wild]

I stand corrected... the problem was not that she didn't have a
system.mdw, she had 3 of them. The problem was that she didn't have
the option for workgroup admin on the menu nor did she have
wrkgadmin.exe on her system. Also, she has the security wizard option
on the menu, but when it is clicked on, she gets a message that the
wizard is not installed. I think I have everything worked out
though, since I will be using a shortcut to the .mdw file when I
implement. She doesn't need the wizard, or wrkgadmin. Thanks for
your help, when I get a chance I will re-install access on her
machine to make sure everything that should be installed is. But for
now I think I'm ok.

Good. If it's version 97 or 2000 you would look for wrkgadm.exe not
wrkgadmin.exe. For later versions the administrator is in the Tools,
security menu.

 

[tw]

thanks for all your help

Good. If it's version 97 or 2000 you would look for wrkgadm.exe not
wrkgadmin.exe. For later versions the administrator is in the Tools,
security menu.