Security change takes effect only locally, not on server

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have a split database with the tables side on a server and the front end
forms, etc., on local machines. I am deploying it to users now. Each local
user has a shortcut with the target pointing to their local access.exe
installation local front end copy of mdb /wrkgrp //UNC location of server
where back end is. Let's call the shortcut target:"c:/office/msaccess.exe"
"c:/database.mdb" /wrkgrp "//server/security.mdw"

My security mdw is on ther server to avoid having to re-link tables locally.
But, here's my problem. I made some changes to the security settings - Added
a new user group and permissions. The changes take effect locally fine, but
they do not take effect on the server unless I relink the tables again.

I'd like to be able to make administrative changes to security settings
without having to re-link all local users. Am I doing something wrong?
 
Ray said:
I have a split database with the tables side on a server and the
front end forms, etc., on local machines. I am deploying it to users
now. Each local user has a shortcut with the target pointing to their
local access.exe installation local front end copy of mdb /wrkgrp
//UNC location of server where back end is. Let's call the shortcut
target:"c:/office/msaccess.exe" "c:/database.mdb" /wrkgrp
"//server/security.mdw"
Click to expand...

UNC pathnames are \\server... not //server
My security mdw is on ther server to avoid having to re-link tables
locally.
Click to expand...

The two really have nothing to do with each other.
But, here's my problem. I made some changes to the security
settings - Added a new user group and permissions. The changes take
effect locally fine, but they do not take effect on the server unless
I relink the tables again.
Click to expand...

You should be joined to the security.mdw on the server when you add users.
The permissions are stored in the mdb. If you've changed permissions on the
backend tables, you should refresh the links in the frontend. If you've
changed permissions in the frontend, you'll have to re-deploy it to the
users, since the permissions are in the mdb.
I'd like to be able to make administrative changes to security
settings without having to re-link all local users. Am I doing
something wrong?
Click to expand...

I think you'll have to clarify what you mean by 'relink all local users'.
 
Joan Wild said:
UNC pathnames are \\server... not //server
Click to expand...

OOps! Of course, you're right. I just made a typo. I have it correct in the
actual shortcut.
The two really have nothing to do with each other.
Click to expand...

Well, before I put the security.mdw on the server, each time a new local
user was added, I had to re-link the tables (on server) to the local user, or
else they could not access any form or report changes.
You should be joined to the security.mdw on the server when you add users.
The permissions are stored in the mdb. If you've changed permissions on the
backend tables, you should refresh the links in the frontend.
Click to expand...

I'm not sure what you mean by refreshing the links, but after I put the
security.mdw on the server and used the /wrkgrp option pointing to the server
with the UNC, I could make changes logged on as Administrator from my local
machine to the forms on the back end, local users did not have to re-link to
make use of the changes.

If you've
changed permissions in the frontend, you'll have to re-deploy it to the
users, since the permissions are in the mdb.
Click to expand...

OK, I'm making the changes to a copy of the mdb which I have locally, using
the /wrkgrp option pointing to the security.mdw on the server. Once, I make
the changes, I copy the edited local.mdb into the server location.
I think you'll have to clarify what you mean by 'relink all local users'.
Click to expand...

This may be what you call refreshing the links.
 
Ok, so once you've made changes in your copy of the frontend (I'm assuming
you are linked to a local copy of the backend, so as not to affect live data
while testing), you then would refresh the links to the live backend (using
the Linked Table mgr).

Then you can copy the frontend to your users (and the links will travel with
it). You can automate the updating of the frontend to users. Have a look
at
http://www.granite.ab.ca/access/autofe.htm
 
maybe someone here can help me. i have been having a problem loading my
antispyware onto my computer. actually my husband downloaded it onto his
account i tried to run a scan under my account and windows is telling me that
there is some type of error module 1904 and to uninstall and reinstall. i've
tried this several times. i also tried to uninstall it from my husband's
account and reinstall under my account nothing has worked can you help me?
 
OK Joan,

Let me see if I've got this straight.

If I understand you correctly, the actual security changes reside in the
front end mdb.

Once I make changes in my copy of the frontend (while linked to my local
copy of the backend), I then have to refresh the links to the live backend
(using the Linked Table mgr).

You have then focused on my problem. Yes, that is the result I am seeing.
So, if I understand you, I still have to re-copy the new frontend to my users
in order to make the changes work for them?

I took a look at the link you sent, but I'm not sure I get exactly how to
configure the program just yet. I'll try to figure it out.

Thanks
Ray
 
Hi Lynn,

This is Ray S. What the heck is this post from RNJ? And why is it quoting my
posted question?

Ray S.
 
Ray said:
If I understand you correctly, the actual security changes reside in
the front end mdb.
Click to expand...

Usernames, passwords, Groups and group membership information reside in the
mdw. When you make these changes, as long as you are using/joined to the
mdw on the server, the changes will occur in that mdw.

Permissions are stored in the mdb file. So if you make changes in your copy
of the frontend, they won't be reflected in users' frontends - how could
they be? You must redeploy the frontend to the users.

Since your copy of the FE is linked to your local copy of the BE, you need
to refresh the links to the live backend before you distribute the FE.
Tony's utility will work fine for you.
 
Joan Wild said:
Tony's utility will work fine for you.
Click to expand...

Joan,
Just another try at this. I have over 200 users in 6 groups. I'm having a
little trouble figuring how to write an .ini file for Tony's utility. Am I
crazy to think that perhaps I could have both the BE and the FE files on the
server with only a shortcut on each user's desktop box? That way, I could
make changes and refresh links once? We are using Access 2000. Does the new
version overcome this? Maybe I can get the company to upgrade...

Ray
 
Ray said:
Joan,
Just another try at this. I have over 200 users in 6 groups. I'm
having a little trouble figuring how to write an .ini file for Tony's
utility. Am I crazy to think that perhaps I could have both the BE
and the FE files on the server with only a shortcut on each user's
desktop box?
Click to expand...

That is not adviseable - it's a recipe for corruption. You don't want all
users using the same frontend.
That way, I could make changes and refresh links once?
Click to expand...

But that is all you need to do. Make changes, refresh links (once), then
copy your frontend to the server. Tony's utility will take care of copying
it to users' machines.
We are using Access 2000. Does the new version overcome this? Maybe I
can get the company to upgrade...
Click to expand...

There is no change in later versions.
 
Ray:

Looks like Joan has given a series of useful replies... and presumably
you've also read the Access Security FAQ.

In case you are still fuzzy on how Access security works, you might
find useful the article and Permissions Explorer tool at my site.

http://grahamwideman.com/gw/tech/access/accesssec/index.htm

http://grahamwideman.com/gw/tech/access/permexpl/index.htm

I don't recommend pointing the tool at an mdw and mdb with 200
users, but in simply trying to figure out your situation you might
create a demo DB with just a few representative users to
see how things work.

Graham
 
Back
Top