If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
Where Is Security Configuration Stored?
Can anyone tell me where are the security settings stored in a situation
where I have a front-end and a back-end for the following: 1. User/Group Accounts: Stored in system file, FE or BE? 2. User/Group Permissions: Stored in system file, FE or BE? Thanks. ck |
#2
|
|||
|
|||
CK wrote:
Can anyone tell me where are the security settings stored in a situation where I have a front-end and a back-end for the following: 1. User/Group Accounts: Stored in system file, FE or BE? 2. User/Group Permissions: Stored in system file, FE or BE? Thanks. ck User info, group info, and membership info is stored in the MDW. Permissions for objects in the front end are stored in the front end. Permissions for objects in the back end are stored in the back end. Makes sense doesn't it? -- I don't check the Email account attached to this message. Send instead to... RBrandt at Hunter dot com |
#3
|
|||
|
|||
Thanks, Rick. Whenever I copied a frontend to bring it home to work, made
some changes to the permissions, and then copied it back to the office, the permissions go haywire so I'm wondering if I should also copy the mdw as well whenever I need to make changes to permissions. ck "Rick Brandt" wrote: CK wrote: Can anyone tell me where are the security settings stored in a situation where I have a front-end and a back-end for the following: 1. User/Group Accounts: Stored in system file, FE or BE? 2. User/Group Permissions: Stored in system file, FE or BE? Thanks. ck User info, group info, and membership info is stored in the MDW. Permissions for objects in the front end are stored in the front end. Permissions for objects in the back end are stored in the back end. Makes sense doesn't it? -- I don't check the Email account attached to this message. Send instead to... RBrandt at Hunter dot com |
#4
|
|||
|
|||
If you're able to work with the frontend at home without the mdw file, then
security probably hasn't been properly applied. -- Doug Steele, Microsoft Access MVP http://I.Am/DougSteele (no e-mails, please!) "CK" wrote in message ... Thanks, Rick. Whenever I copied a frontend to bring it home to work, made some changes to the permissions, and then copied it back to the office, the permissions go haywire so I'm wondering if I should also copy the mdw as well whenever I need to make changes to permissions. ck "Rick Brandt" wrote: CK wrote: Can anyone tell me where are the security settings stored in a situation where I have a front-end and a back-end for the following: 1. User/Group Accounts: Stored in system file, FE or BE? 2. User/Group Permissions: Stored in system file, FE or BE? Thanks. ck User info, group info, and membership info is stored in the MDW. Permissions for objects in the front end are stored in the front end. Permissions for objects in the back end are stored in the back end. Makes sense doesn't it? -- I don't check the Email account attached to this message. Send instead to... RBrandt at Hunter dot com |
#5
|
|||
|
|||
"CK" wrote in message
... Thanks, Rick. Whenever I copied a frontend to bring it home to work, made some changes to the permissions, and then copied it back to the office, the permissions go haywire so I'm wondering if I should also copy the mdw as well whenever I need to make changes to permissions. Well, you would have at least needed a copy of the workgroup file. If you can move the mdb file to different machine, and open it with a different mdw file, then your security has been setup wrong (what kind of security would that be?). So, you can ONLY open the mdb file with the original workgroup file used to secure it. (or a new workgroup file created with the same passwords used). Assuming, thus that you likely do have a copy of the workgroup file at home, then, yes..you can make security changes, and take them back to work. However, keep in mind two things: You should NEVER NEVER set security for a form, report, query etc to a actual INDIVIDUAL!!! The INSTANT you do this, you have now in fact put security for users in the mdb file. You have a choice he when you set security/permissions for a form, report etc, ALWAYS set those permissions to a SECURITY GROUP not a USER!!!! By doing this, means you can work on a copy of the front end, and also take home a copy of the security workgroup file. During the week, I sure that new users are being added to the system. Further, I sure over time, some users will be given permissions to use a particular form etc. However, since we ALWAYS assign users to security groups, then in fact we NEVER assign a user to a form, but only security groups. This means that as you add new forms, or reports in your application, you simply assign that report, or form to a EXISTING security group (say, the sales group, or perhaps the manager group, or the 'read only' group). This way, you can re-deploy a new front end to the company on site, but develop off site. All of the many complex changes and assigning of users to security groups will thus continue to work, and yet you don't care, or even need their security workgroup file. The instant you break the above rule, and start assigning forms to actual users, then in fact that security is CONTAINED IN THE MDB file!!! So, don't do that!! At the end of the day, most applications I have written can be broken down in to maybe 3, or 5 major security groups. There is some great screen shots, and an example of the security groups I used he http://www.members.shaw.ca/AlbertKal...erFriendly.htm So, the major trick to making this work is to sit down, and build 3 or 5 security groups. Then as you develop the application, you ALWAYS assign forms and reports to those security groups. It is only your clients that will assign users to those actual security groups, but those settings are contained in the workgroup file. So, you have 100% complete freedom to email, or simply update your users front end. The instant you allow your client to add new security groups, or allow them to assign users to a particular form, then any update you send to them will LOOSE those settings. So, as a developer, make the security groups for the client, and as you develop, assign forms, reports etc. to those security groups. And, like I did, you might want to spend part of a afternoon, and make a few nice security manager screens that makes this stuff VERY easy for your clients... -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada http://www.members.shaw.ca/AlbertKallal |
#6
|
|||
|
|||
Thanks Albert for the invaluable tips. As it happened, I had the original mdw
file which I first created with some users and groups in my home computer but over time, the original mdw file in my home and the one in the office is no more the same because of changes done to the one in the office. For example when I added a new user, it was not reflected in my home computer. This is a good reminder for me to also copy the mdw file whenever I need to bring the frontend home to work, just in case. One of the reasons I wanted to clarify this was that I noticed that the mdw file doesn't seem to change in file size at all despite all the changes which led me to suspect that maybe the configuration is stored somewhere else. ck |
#7
|
|||
|
|||
Thanks. See my reply to Albert.
ck |
#8
|
|||
|
|||
For example
when I added a new user, it was not reflected in my home computer. This is a good reminder for me to also copy the mdw file whenever I need to bring the front-end home to work, just in case. Yes, as mentioned, you can do the above. however, you need a fresh copy of the workgroup file, as long as you following the rules outlined in my previous post. If take the approach I mentioned, then, you don't care if changes occur "on site" to the workgroup file. They can add, delete users and set permissions for users to groups, and you are STILL FREE to send them new updates, and NOTHING will go wrong. -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada http://www.members.shaw.ca/AlbertKallal |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Convert FoxPro 2.6 Code to MsAccess 2003 | RNUSZ@OKDPS | Setting Up & Running Reports | 6 | April 30th, 2005 12:30 PM |
Encrypt AccesS File? | milest | General Discussion | 2 | February 9th, 2005 07:58 PM |
Pass parameter to stored procedure and security questions | souris | General Discussion | 4 | February 9th, 2005 04:56 AM |
Unsafe Attachments | Ron | Installation & Setup | 2 | June 9th, 2004 01:55 AM |