|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Security change takes effect only locally, not on serverI 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 S. wrote:
> I have a split database with the tables side on a server and the UNC pathnames are \\server... not //server> 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 The two really have nothing to do with each other.> locally. > But, here's my problem. I made some changes to the security You should be joined to the security.mdw on the server when you add users. > 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. 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 I think you'll have to clarify what you mean by 'relink all local users'.> settings without having to re-link all local users. Am I doing > something wrong? -- Joan Wild Microsoft Access MVP "Joan Wild" wrote: OOps! Of course, you're right. I just made a typo. I have it correct in the > Ray S. wrote: > > 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" > > UNC pathnames are \\server... not //server actual shortcut. > Well, before I put the security.mdw on the server, each time a new local > > My security mdw is on ther server to avoid having to re-link tables > > locally. > > The two really have nothing to do with each other. 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. > I'm not sure what you mean by refreshing the links, but after I put the > > 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. > > 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. 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 OK, I'm making the changes to a copy of the mdb which I have locally, using > users, since the permissions are in the mdb. > 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'd like to be able to make administrative changes to security This may be what you call refreshing the links.> > settings without having to re-link all local users. Am I doing > > something wrong? > > I think you'll have to clarify what you mean by 'relink all local users'. Show quoteHide quote > > -- > Joan Wild > Microsoft Access MVP > > > 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 -- Show quoteHide quoteJoan Wild Microsoft Access MVP Ray S. wrote: > "Joan Wild" wrote: > >> Ray S. wrote: >>> 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" >> >> UNC pathnames are \\server... not //server > > OOps! Of course, you're right. I just made a typo. I have it correct > in the actual shortcut. > >> >>> My security mdw is on ther server to avoid having to re-link tables >>> locally. >> >> The two really have nothing to do with each other. > > 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. > >> >>> 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. >> >> 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. > > 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. >> > > 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'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? >> >> I think you'll have to clarify what you mean by 'relink all local >> users'. > > This may be what you call refreshing the links. > >> >> -- >> Joan Wild >> Microsoft Access MVP 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 Ray S. wrote:
> If I understand you correctly, the actual security changes reside in Usernames, passwords, Groups and group membership information reside in the > the front end mdb. 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 Microsoft Access MVP "Joan Wild" wrote: Joan,> Tony's utility will work fine for you. > -- > Joan Wild > Microsoft Access MVP 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 S. wrote:
> That is not adviseable - it's a recipe for corruption. You don't want all > 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? users using the same frontend. > That way, I could make changes and refresh links once? 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 There is no change in later versions.> can get the company to upgrade... -- Joan Wild Microsoft Access MVP 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? Show quoteHide quote "Ray S." wrote: > 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? Hi,
I suspect that you will need to contact the antispyware company or, else, ask your question in a newsgroup dedicated to antispyware software. This newsgroup is dedicated to MS Access, the database product that is part of the MS Office Suite. -- Show quoteHide quoteLynn Trapp MS Access MVP www.ltcomputerdesigns.com Access Security: www.ltcomputerdesigns.com/Security.htm Jeff Conrad's Access Junkie List: http://home.bendbroadband.com/conradsystems/accessjunkie.html "RNJ" <skeeta1***@discussion.com> wrote in message news:68816266-4523-4FA3-8D9B-E5DA5BE909B1@microsoft.com... > 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? > > "Ray S." wrote: > >> 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? Hi Lynn,
This is Ray S. What the heck is this post from RNJ? And why is it quoting my posted question? Ray S. Well, Ray, I suspect that RNJ posted as a reply to your post. I can't tell
you WHY. -- Show quoteHide quoteLynn Trapp MS Access MVP www.ltcomputerdesigns.com Access Security: www.ltcomputerdesigns.com/Security.htm Jeff Conrad's Access Junkie List: http://home.bendbroadband.com/conradsystems/accessjunkie.html "Ray S." <R***@discussions.microsoft.com> wrote in message news:354F316C-4F8A-4A8A-8924-499D096D690E@microsoft.com... > 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:
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 
Other interesting topics
TC - New security model
Share Workgroup Information File Access Security When called from .NET You do not have Exclusive acces to the database at this time????? Relink tables in a secured DB - create table permission required? Database on network , but if 1 user logs in others are locked out Export or Import Objects from One Secured Database to Another Re: Overall Security??? Locked out of all Access DBs Can't create new forms |
|||||||||||||||||||||||
