Problem switching between Workgroups

  • Thread starter Thread starter ragtopcaddy via AccessMonster.com
  • Start date Start date
R

ragtopcaddy via AccessMonster.com

I have the following targets in 2 different shortcuts:

"C:\Program Files\Microsoft Office\Office10\MSACCESS.EXE" "\\Server\TestEnv\
Repo_processBR.mdb" /wrkgrp "\\Server\settings\Application Data\Microsoft\
Access\MBSHCDB.mdw" /User "Administrator" /pwd "*********"

"C:\Program Files\Microsoft Office\Office10\MSACCESS.EXE" "\\Server\TestEnv\
Repo_processBR.mdb" /wrkgrp "\\Server\settings\Application Data\Microsoft\
Access\System.mdw"

When I use the 2nd shortcut, the workgroup administrator shows me as still
joined to the workgroup in the 1st shortcut. Any idea why?

Thanks,

Bill R
 
The workgroup administrator in Tools, security does *not* tell you the
current mdw in use. It just tells you what your default mdw is. When you
use a shortcut with the /wrkgrp switch, it is using that workgroup file for
that session - regardless of what the default is set to.

In your case, your default mdw is set to your MBSHCDB.mdw workgroup. You
likely should rejoin the standard system.mdw that ships with Access.

If you want to verify the mdw in use, open via your shortcut, hit Ctrl-G and
type
?DbEngine.SystemDb

That'll tell you the path to the one in use.
 
Thank you Joan.

If I have to manually open the administrator and rejoin the system.mdw,
regardless of what the shortcut says, then what is the point of using the
/wkgrp switch?

Bill

Joan said:
The workgroup administrator in Tools, security does *not* tell you the
current mdw in use. It just tells you what your default mdw is. When you
use a shortcut with the /wrkgrp switch, it is using that workgroup file for
that session - regardless of what the default is set to.

In your case, your default mdw is set to your MBSHCDB.mdw workgroup. You
likely should rejoin the standard system.mdw that ships with Access.

If you want to verify the mdw in use, open via your shortcut, hit Ctrl-G and
type
?DbEngine.SystemDb

That'll tell you the path to the one in use.
I have the following targets in 2 different shortcuts:
Click to expand...
[quoted text clipped - 20 lines]
Click to expand...
 
You want your default to be system.mdw. That is the workgroup that ships
with Access and is used in all sessions. It requires no login, and silently
logs you in as "Admin".

So you'd normally want that to be the workgroup you use in most sessions -
i.e. for all unsecured databases.

For your secure databases, you'd use a desktop shortcut with the /wrkgrp
which will override the default (system.mdw) for *just that session*.

When you open an unsecured database, it'll use the system.mdw.

You happen to have your secure mdw (requires a login) set as your default.
That means for any 'unsecured' database you try to open, it'll use that
secure.mdw and require a login - not something you'd want.

So rejoin system.mdw and use the shortcuts for all secure mdbs.


--
Joan Wild
Microsoft Access MVP
Thank you Joan.

If I have to manually open the administrator and rejoin the
system.mdw, regardless of what the shortcut says, then what is the
point of using the /wkgrp switch?

Bill

Joan said:
The workgroup administrator in Tools, security does *not* tell you
the current mdw in use. It just tells you what your default mdw is.
When you use a shortcut with the /wrkgrp switch, it is using that
workgroup file for that session - regardless of what the default is
set to.

In your case, your default mdw is set to your MBSHCDB.mdw workgroup.
You likely should rejoin the standard system.mdw that ships with
Access.

If you want to verify the mdw in use, open via your shortcut, hit
Ctrl-G and type
?DbEngine.SystemDb

That'll tell you the path to the one in use.
I have the following targets in 2 different shortcuts:
Click to expand...
[quoted text clipped - 20 lines]
Click to expand...
Click to expand...
 
Joan,

Thanks for the clarification. It's been a while since I last implemented
Access security.

I successfully used the same method to secure a different db that I had
created a month ago (same for the 2nd db I'm not having any luck with). The
1st db works just fine, the 2nd doesn't.

In both cases I want to set the default Admin user to be restricted to read
only. So that when a user logged into the default system.mdw opens the db by
any method, he can only read data or designs. The only way to edit data is to
log in with the shortcut that opens MBSHCDB.mdw using the administrator logon
and pwd.

I implemented this with the desired results in the 1st db.

I then opened the 2nd db using this MBSHCDB.mdw and set Admin's permissions
to read data and read design for all existing objects in the db.

Then I closed it and opened it while joined to the system.mdw.

My security changes had no effect. I was able to open the db (presumably as
Admin with no logon) and make changes to data in tables that I had restriced
to read data and read design for Admin.

I can't see where I've gone wrong.

Thanks,

Bill

Joan said:
You want your default to be system.mdw. That is the workgroup that ships
with Access and is used in all sessions. It requires no login, and silently
logs you in as "Admin".

So you'd normally want that to be the workgroup you use in most sessions -
i.e. for all unsecured databases.

For your secure databases, you'd use a desktop shortcut with the /wrkgrp
which will override the default (system.mdw) for *just that session*.

When you open an unsecured database, it'll use the system.mdw.

You happen to have your secure mdw (requires a login) set as your default.
That means for any 'unsecured' database you try to open, it'll use that
secure.mdw and require a login - not something you'd want.

So rejoin system.mdw and use the shortcuts for all secure mdbs.
Thank you Joan.
Click to expand...
[quoted text clipped - 32 lines]
Click to expand...

--
Bill Reed

"If you can't laugh at yourself, laugh at somebody else"

Message posted via AccessMonster.com
 
ragtopcaddy said:
In both cases I want to set the default Admin user to be restricted
to read only. So that when a user logged into the default system.mdw
opens the db by any method, he can only read data or designs. The
only way to edit data is to log in with the shortcut that opens
MBSHCDB.mdw using the administrator logon and pwd.

I then opened the 2nd db using this MBSHCDB.mdw and set Admin's
permissions to read data and read design for all existing objects in
the db.

Then I closed it and opened it while joined to the system.mdw.

My security changes had no effect. I was able to open the db
(presumably as Admin with no logon) and make changes to data in
tables that I had restriced to read data and read design for Admin.
Click to expand...

Go back and remove all permissions from Admin. Now as a test, open your
'secure' mdb using system.mdw.

If you are able to even open the mdb, then you missed a step in securing it.
Likely the Users Group has permissions, or the Admin user owns objects. Fix
the problem. When you have it correct, you shouldn't be able to open the
mdb using system.mdw.

Once you have it secured properly, then login to the mdb and grant
permissions to the Users Group (rather than the Admin User) that you want
the 'world' to have.

Then test using system.mdw and make sure that the security is working as
expected.
 
Joan,

Thanks for all your help. I got the thing working correctly.

Bill

Joan said:
In both cases I want to set the default Admin user to be restricted
to read only. So that when a user logged into the default system.mdw
Click to expand...
[quoted text clipped - 11 lines]
(presumably as Admin with no logon) and make changes to data in
tables that I had restriced to read data and read design for Admin.
Click to expand...

Go back and remove all permissions from Admin. Now as a test, open your
'secure' mdb using system.mdw.

If you are able to even open the mdb, then you missed a step in securing it.
Likely the Users Group has permissions, or the Admin user owns objects. Fix
the problem. When you have it correct, you shouldn't be able to open the
mdb using system.mdw.

Once you have it secured properly, then login to the mdb and grant
permissions to the Users Group (rather than the Admin User) that you want
the 'world' to have.

Then test using system.mdw and make sure that the security is working as
expected.
Click to expand...

--
Bill Reed

"If you can't laugh at yourself, laugh at somebody else"

Message posted via AccessMonster.com
 
Back
Top