Security setup, completely lost

[Guest]

Alright, this one is really got me stumped. (Access 2003)
Did the set up step by step.

Got error message: Error 'An unexpected error occured while changing the
owner of the db. This problem can occur if you have (1) previously created
the db while logged on as one user, (2) previously used the Security Wizard
in any version of Access, and then (3) logged on as a different user to run
the Security Wizard this time' The wizard can't complete successfully.

First I'm not sure what that means, but I got some advice to make sure thatI
start out with only one mdw file, the default System.mdw. Did that. Also
was adviced to make sure my db wasn't previously 'secured' in any way. To
this I created a new db after all my failed attempts of .mdw files were
deleted and I thought I was starting out fresh.

Well, I create a new user in step 7 of the Step-by-Step process and when I
get to step 12, it won't recognize my user I created in step 7. I continued
using the default Admin user just to see what happens and that when I get the
Error.

So either way I've totally messed something up. I don't know why this is so
hard, but it is. If you have any advice please help.

And I guess you should try to explain it to me like I'm a 5 year old, cause
otherwise i'm gonna get lost. Thanks.

 

[Joan Wild]

Alright, this one is really got me stumped. (Access 2003)
Did the set up step by step.

First I'm not sure what that means, but I got some advice to make sure thatI
start out with only one mdw file, the default System.mdw. Did that.

Just because it's named that, doesn't mean it's a pristine workgroup file. I would delete all mdw files. Start up Access, and it'll create a new clean system.mdw for you.

Also
was adviced to make sure my db wasn't previously 'secured' in any way. To
this I created a new db after all my failed attempts of .mdw files were
deleted and I thought I was starting out fresh.

Yes create a new mdb and import everything from you old mdb.

Well, I create a new user in step 7 of the Step-by-Step process and when I
get to step 12, it won't recognize my user I created in step 7.

So either way I've totally messed something up. I don't know why this is so
hard, but it is. If you have any advice please help.

Security is hard to get right. I don't know anyone who got it 'right' the first time through.

I gather that you are following the steps in the security FAQ. It is important that you follow each and every step (don't pass over anything).

If you'd like to try again, go back to your unsecured backup (you have one right?), delete or rename all mdw files you have on your computer, and start over. The security wizard in 2003 does a better job than earlier versions. You might like to the try the detailed steps I've outlined at www.jmwild.com/security02.htm

 

[Guest]

Joan,

I got it to work. Apparently there was something about my 'unsecured' db
that was messing it up.

However, I have one more problem. Now that I have the 'test' db working
with a log in on my computer, the version I put on the share drive doesn't
have the log on prompt for my test user. Is there some special process I
need to do to get the that part of it to work, Or did I still mess something
up.

Thanks for all your help so far.

 

[Joan Wild]

Joan,

I got it to work. Apparently there was something about my 'unsecured' db
that was messing it up.

However, I have one more problem. Now that I have the 'test' db working
with a log in on my computer, the version I put on the share drive doesn't
have the log on prompt for my test user.

If you mean they are able to just open the mdb via Windows Explorer, then you didn't secure it properly. That is actually a good test to see if you did it right.While joined to the standard system.mdw workgroup file, you shouldn't be able to even open the mdb.

 

[Guest]

I see, but I don't understand why the log in prompt would come up when I run
the DB from my computer and it not come up on someone else's. That doesn't
make sense to me? Should I just try again.

 

[Joan Wild]

Every session of Access uses a mdw file (even for unsecured databases). Out of the box it comes with system.mdw and uses that, silently logging you in as a user named 'Admin' who owns everything and has permissions to everything. Every system.mdw is the same, which is why you can freely copy mdb files around - Admin is the same and so can open/use any unsecured mdb file.

When you implement security, you remove all permissions from the Users Group and the Admin User (these two entities are common to all mdw files), and you ensure that the Admin User doesn't own anything. You do this in a new mdw file.

If you've done things right, then opening your mdb while using the standard system.mdw shouldn't work, since they would be using the mdb as 'Admin' which shouldn't have any permissions.

There is always *some* mdw file set as the default to use. It's likely on your computer that your secure mdw is set as the default, and so you get the login prompt. On the other person's computer, system.mdw is likely set as the default.

You should use the workgroup administrator on your computer to change your default back to system.mdw. Then use a desktop shortcut to launch your secure mdb. The shortcut will use the /wrkgrp switch which will override the default mdw for that session. The target of the shortcut would look like:
"path to msaccess.exe" "path to mdb" /wrkgrp "path to secure mdw"

 

[Guest]

Okay, one more step completed. I think. Now I'm getting a 3033 error. Is
that because I didn't set up a shortcut. I guessing all I have to do for
that is make a shortcut from the DB and instruct my user to use that? Or is
there more to it?

 

[Joan Wild]

Each user should have a copy of the frontend and the shortcut.
"path to msaccess.exe" "path to frontend" /wrkgrp "path to secure mdw"

The path to the secure mdw can be a UNC path like \\servername\share\path\whatever.mdw

--
Joan Wild
Microsoft Access MVP

Okay, one more step completed. I think. Now I'm getting a 3033 error. Is
that because I didn't set up a shortcut. I guessing all I have to do for
that is make a shortcut from the DB and instruct my user to use that? Or is
there more to it?

 

[Guest]

Okay, that's a bit over my head. I'm not sure how to do that. Is there a
reason why this is so difficult?

 

[Joan Wild]

Try and copy the shortcut you have on your desktop (it's just a file with a lnk extension) to the other user's desktop and see if it works.

 

[Guest]

Here's an interesting thing. When I have Access linked to the seured mdw
file the log in works fine for my computer, but my user gets a 3033 error.
When I switch to the default system.mdw I can just cruise right in to the db
without a log in.

I would say that means the security is not set right. Perhaps I need to
rethink the necessity of seurity. All I need it to make it so my users can
change forms, delete tables, that sort of thing. I was under the impression
securing the db was the only way to do that.

It would appear that I'm not going to solve this problem. I seem to be
missing something in all these steps. Is there something commonly overlooked
that I might be missing?

 

[Rick Brandt]

Okay, that's a bit over my head. I'm not sure how to do that. Is
there a reason why this is so difficult?

There are certain tasks (like brain surgery) where the statement "How do
I...?" automatically means you are not qualified to perform that task.
Access user level security just about falls into that category. It is not
THAT difficult to comnprehend for a seasoned Access pro, but it is often
attempted by people who are relatively new to Access and application
development in general and in those cases "getting it" is really a
challenge.

Step one is to realize that ULS is not just something you "do to a file"
like applying a password is. It is the setting up of a system of
inter-related objects that as a whole contain all of the information
required for the "secured system", and yet the individual components really
don't know anything about each other directly. There is no "link" between a
secured MDB file and the MDW file that allows you to open it.

There is information in the MDW file that is loaded into the Access session.
There is information in the MDB file concerning permissions. When a
particular MDW is used in an Access session and that session then tries to
open a particular MDB file it is the combination of the data pulled from the
two files that decides whether the file can be opened and then (if you CAN
open the file) whether you have permissions to the various objects within
the file.