|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
WRKGADM.EXEWhere is the WRKGADM.EXE file located in Access 2003, I did a search on the
users PC and I can find it There is a way to open the workgroup administrator from within Access. This
was added I believe since Access 2000....go to Tools-->Security-->Workgroup administrator. Show quoteHide quote "geocoy" wrote: > Where is the WRKGADM.EXE file located in Access 2003, I did a search on the > users PC and I can find it OUCH! That changes the concept of the secure database and sharing. Is there
an instruction on how to allow users to share a secure database? Show quoteHide quote "Ray C" wrote: > There is a way to open the workgroup administrator from within Access. This > was added I believe since Access 2000....go to Tools-->Security-->Workgroup > administrator. > > "geocoy" wrote: > > > Where is the WRKGADM.EXE file located in Access 2003, I did a search on the > > users PC and I can find it geocoy wrote:
> OUCH! That changes the concept of the secure database and sharing. How exactly?> Is there an instruction on how to allow users to share a secure Create for them a shortcut that specifies the appropriate workgroup file as a > database? command line argument. That has been the recommended practice for all versions. -- Rick Brandt, Microsoft Access MVP Email (as appropriate) to... RBrandt at Hunter dot com Well I always created a workgroup file and linked the database to the
appropriate file (thru the WRKGADM.EXE ) when I installed the databse for them. So if I undestand you right, I still do the same thing, but I make the link within Access. It just struck me odd when you said that. That should work. Let me know if I am wrong about this Show quoteHide quote "Rick Brandt" wrote: > geocoy wrote: > > OUCH! That changes the concept of the secure database and sharing. > > How exactly? > > > Is there an instruction on how to allow users to share a secure > > database? > > Create for them a shortcut that specifies the appropriate workgroup file as a > command line argument. That has been the recommended practice for all versions. > > > -- > Rick Brandt, Microsoft Access MVP > Email (as appropriate) to... > RBrandt at Hunter dot com > > > geocoy wrote:
> Well I always created a workgroup file and linked the database to the There is no "link" between an Access database file and a workgroup file. The > appropriate file (thru the WRKGADM.EXE ) when I installed the databse > for them. So if I undestand you right, I still do the same thing, > but I make the link within Access. It just struck me odd when you > said that. That should work. Let me know if I am wrong about this workgroup is tied to the "session", not the file. There is a coincidental relationship between a secured mdb and a workgroup that will allow you to open it, but it is best not to describe that as a "link" because it is in fact not a link. The mdb "knows" what groups and/or users are allowed to open it and what those groups and/or users can do once allowed in the file. The user and group memberships are established when you start an Access session with a particular workgroup file. When you attempt to open an mdb during an Access session the established user and group memberships are examined to see if adequate credentials exist to open the file. If they do you are in, otherwise you get an error. If you wanted to you could make any number of completely different workgroup files that would all allow access to a particular secured mdb file. The fact that there is usually only one such file is what leads people to believe that the two files are linked. -- Rick Brandt, Microsoft Access MVP Email (as appropriate) to... RBrandt at Hunter dot com Interesting comment, I see what you mean, I assumed it was linked because
when you use the WRKGADM.EXE to "link" to the appropriate file, I think it uses the work link in the dialog box. I have been making a copy of the latest version of the workgroup file and putting it in a folder called C:\Purge (Purge is the name of my database) along with the database itself. The workgroup file never gets updated unless I give the user an updated copy. I figured the user has no need to have an updated version unless I make change to his version of the front end database that might affect the way the database works. Do you think this is good practice apposed to putting a single copy of a workgroup file on the network for all users to access a single workgroup file. I'd be curious to know the implications. Show quoteHide quote "Rick Brandt" wrote: > geocoy wrote: > > Well I always created a workgroup file and linked the database to the > > appropriate file (thru the WRKGADM.EXE ) when I installed the databse > > for them. So if I undestand you right, I still do the same thing, > > but I make the link within Access. It just struck me odd when you > > said that. That should work. Let me know if I am wrong about this > > There is no "link" between an Access database file and a workgroup file. The > workgroup is tied to the "session", not the file. > > There is a coincidental relationship between a secured mdb and a workgroup that > will allow you to open it, but it is best not to describe that as a "link" > because it is in fact not a link. > > The mdb "knows" what groups and/or users are allowed to open it and what those > groups and/or users can do once allowed in the file. The user and group > memberships are established when you start an Access session with a particular > workgroup file. > > When you attempt to open an mdb during an Access session the established user > and group memberships are examined to see if adequate credentials exist to open > the file. If they do you are in, otherwise you get an error. > > If you wanted to you could make any number of completely different workgroup > files that would all allow access to a particular secured mdb file. The fact > that there is usually only one such file is what leads people to believe that > the two files are linked. > > -- > Rick Brandt, Microsoft Access MVP > Email (as appropriate) to... > RBrandt at Hunter dot com > > > geocoy wrote:
> Interesting comment, I see what you mean, I assumed it was linked It is best to have one shared workgroup file on the LAN and to assign > because when you use the WRKGADM.EXE to "link" to the appropriate > file, I think it uses the work link in the dialog box. I have been > making a copy of the latest version of the workgroup file and putting > it in a folder called C:\Purge (Purge is the name of my database) > along with the database itself. The workgroup file never gets > updated unless I give the user an updated copy. I figured the user > has no need to have an updated version unless I make change to his > version of the front end database that might affect the way the > database works. Do you think this is good practice apposed to > putting a single copy of a workgroup file on the network for all > users to access a single workgroup file. I'd be curious to know the > implications. permissions only to groups, never to individuals. That way you maintain a single workgroup file and the only maintenance is adding people to groups or removing them from groups. It also means you can make those kinds of changes to the workgroup file and the MDB will not need to be updated at the same time. If you grant permissions at the user level you are forever having to update both files to make changes. -- Rick Brandt, Microsoft Access MVP Email (as appropriate) to... RBrandt at Hunter dot com Understood. I should have explained myself better. At this point the only
thing that gets changed is that I am adding new users and I do have them in groups. Old versions of Access was slugish over networks, so I was trying my best to keep as much of the activities local as possible. When new users need to add a record it is all don't locally until they choose to save, at which point the information is appended to the back end database. The only time they are working across the network is when they want to view or edit records. So I was using the same logic for the workgroup file, if it is located on the users pc, he is almost never running anything across the network. When I add a new user, I just give him required access and a fresh copy of the frontend and workgroup file he needs to get permissions. The last added user is the only one with an up to date worrkgroup file. Show quoteHide quote "Rick Brandt" wrote: > geocoy wrote: > > Interesting comment, I see what you mean, I assumed it was linked > > because when you use the WRKGADM.EXE to "link" to the appropriate > > file, I think it uses the work link in the dialog box. I have been > > making a copy of the latest version of the workgroup file and putting > > it in a folder called C:\Purge (Purge is the name of my database) > > along with the database itself. The workgroup file never gets > > updated unless I give the user an updated copy. I figured the user > > has no need to have an updated version unless I make change to his > > version of the front end database that might affect the way the > > database works. Do you think this is good practice apposed to > > putting a single copy of a workgroup file on the network for all > > users to access a single workgroup file. I'd be curious to know the > > implications. > > It is best to have one shared workgroup file on the LAN and to assign > permissions only to groups, never to individuals. That way you maintain a > single workgroup file and the only maintenance is adding people to groups or > removing them from groups. It also means you can make those kinds of > changes to the workgroup file and the MDB will not need to be updated at the > same time. If you grant permissions at the user level you are forever > having to update both files to make changes. > > > -- > Rick Brandt, Microsoft Access MVP > Email (as appropriate) to... > RBrandt at Hunter dot com > > > geocoy wrote:
Show quoteHide quote > Understood. I should have explained myself better. At this point A reasonable sentiment, but the activity on the workgroup file is neglible when > the only thing that gets changed is that I am adding new users and I > do have them in groups. > > Old versions of Access was slugish over networks, so I was trying my > best to keep as much of the activities local as possible. When new > users need to add a record it is all don't locally until they choose > to save, at which point the information is appended to the back end > database. The only time they are working across the network is when > they want to view or edit records. > > So I was using the same logic for the workgroup file, if it is > located on the users pc, he is almost never running anything across > the network. When I add a new user, I just give him required access > and a fresh copy of the frontend and workgroup file he needs to get > permissions. The last added user is the only one with an up to date > worrkgroup file. compared to that of the data file. I doubt you would be able to measure a difference. -- Rick Brandt, Microsoft Access MVP Email (as appropriate) to... RBrandt at Hunter dot com In addition, if a user has changed their password, you'll overwrite it when
you provide the updated mdw. It is better to put it on the server. -- Show quoteHide quoteJoan Wild Microsoft Access MVP "Rick Brandt" <rickbran***@hotmail.com> wrote in message news:wj0Kh.9295$P47.6886@newssvr22.news.prodigy.net... > geocoy wrote: >> Understood. I should have explained myself better. At this point >> the only thing that gets changed is that I am adding new users and I >> do have them in groups. >> >> Old versions of Access was slugish over networks, so I was trying my >> best to keep as much of the activities local as possible. When new >> users need to add a record it is all don't locally until they choose >> to save, at which point the information is appended to the back end >> database. The only time they are working across the network is when >> they want to view or edit records. >> >> So I was using the same logic for the workgroup file, if it is >> located on the users pc, he is almost never running anything across >> the network. When I add a new user, I just give him required access >> and a fresh copy of the frontend and workgroup file he needs to get >> permissions. The last added user is the only one with an up to date >> worrkgroup file. > > A reasonable sentiment, but the activity on the workgroup file is neglible > when compared to that of the data file. I doubt you would be able to > measure a difference. > > -- > Rick Brandt, Microsoft Access MVP > Email (as appropriate) to... > RBrandt at Hunter dot com > > "Joan Wild" <jwild@nospamtyenet.com> wrote in BTW, the situation in which I copy down the workgroup file with eachnews:u3E6ziyZHHA.348@TK2MSFTNGP02.phx.gbl: > In addition, if a user has changed their password, you'll > overwrite it when you provide the updated mdw. It is better to > put it on the server. update is one in which users don't have passwords. They don't even know they are being logged on (it uses the Windows logon, mapped to an account in the workgroup file; now that I've found code to make it easy to work with Active Directory Organizational Units, I'll never have to do that again). "Rick Brandt" <rickbran***@hotmail.com> wrote in Not true in all scenarios. Contention for the workgroup file cannews:wj0Kh.9295$P47.6886@newssvr22.news.prodigy.net: > A reasonable sentiment, but the activity on the workgroup file is > neglible when compared to that of the data file. I doubt you > would be able to measure a difference. lead to concurrency problems. I had a situation in the early days of A2K where this was an issue with a mere 10 users, and so we moved the workgroup files to the workstations. It's copied down again each time the user installs a new front end. David W. Fenton wrote:
> "Rick Brandt" <rickbran***@hotmail.com> wrote in Seems odd that that would happen when the workgroup file is only being read > news:wj0Kh.9295$P47.6886@newssvr22.news.prodigy.net: > >> A reasonable sentiment, but the activity on the workgroup file is >> neglible when compared to that of the data file. I doubt you >> would be able to measure a difference. > > Not true in all scenarios. Contention for the workgroup file can > lead to concurrency problems. I had a situation in the early days of > A2K where this was an issue with a mere 10 users, and so we moved > the workgroup files to the workstations. It's copied down again each > time the user installs a new front end. from. Concurency should only be an issue when writing to the file no? -- Rick Brandt, Microsoft Access MVP Email (as appropriate) to... RBrandt at Hunter dot com
Show quote
Hide quote
"Rick Brandt" <rickbran***@hotmail.com> wrote in We were getting locking issues in the LDB file of the workgroupnews:0TfKh.5867$JZ3.5854@newssvr13.news.prodigy.net: > David W. Fenton wrote: >> "Rick Brandt" <rickbran***@hotmail.com> wrote in >> news:wj0Kh.9295$P47.6886@newssvr22.news.prodigy.net: >> >>> A reasonable sentiment, but the activity on the workgroup file >>> is neglible when compared to that of the data file. I doubt you >>> would be able to measure a difference. >> >> Not true in all scenarios. Contention for the workgroup file can >> lead to concurrency problems. I had a situation in the early days >> of A2K where this was an issue with a mere 10 users, and so we >> moved the workgroup files to the workstations. It's copied down >> again each time the user installs a new front end. > > Seems odd that that would happen when the workgroup file is only > being read from. Concurency should only be an issue when writing > to the file no? file. Remember that records *do* get written to the LDB file. At the time it was an NT 4 server, and it was tuned the same way as any other NT 4 server I'd ever used, including with shared workgroup files. It may have been something specific to that network, and it may have been related to the fact that all workstations were Win2K, at a time when that was fairly new (this was back in 2000). I stand corrected, its a join
Show quoteHide quote "Rick Brandt" wrote: > geocoy wrote: > > Well I always created a workgroup file and linked the database to the > > appropriate file (thru the WRKGADM.EXE ) when I installed the databse > > for them. So if I undestand you right, I still do the same thing, > > but I make the link within Access. It just struck me odd when you > > said that. That should work. Let me know if I am wrong about this > > There is no "link" between an Access database file and a workgroup file. The > workgroup is tied to the "session", not the file. > > There is a coincidental relationship between a secured mdb and a workgroup that > will allow you to open it, but it is best not to describe that as a "link" > because it is in fact not a link. > > The mdb "knows" what groups and/or users are allowed to open it and what those > groups and/or users can do once allowed in the file. The user and group > memberships are established when you start an Access session with a particular > workgroup file. > > When you attempt to open an mdb during an Access session the established user > and group memberships are examined to see if adequate credentials exist to open > the file. If they do you are in, otherwise you get an error. > > If you wanted to you could make any number of completely different workgroup > files that would all allow access to a particular secured mdb file. The fact > that there is usually only one such file is what leads people to believe that > the two files are linked. > > -- > Rick Brandt, Microsoft Access MVP > Email (as appropriate) to... > RBrandt at Hunter dot com > > > geocoy wrote:
> I stand corrected, its a join Yes, but YOU are "joining" the workgroup which is just another way of saying "Make this workgroup file my default". The WRKGADM.EXE program has no knowledge and no concern about what file(s) you might try to operate while joined to that workgroup. All it does it let you make new workgroup files and specify which one is your default. The fact that you might join a workgroup while you have a particular MDB file open again means absolutely nothing to that process. You could do the same thing with some other MDB file open or with no MDB file opened. -- Rick Brandt, Microsoft Access MVP Email (as appropriate) to... RBrandt at Hunter dot com 
Other interesting topics
|
|||||||||||||||||||||||
