WRKGADM.EXE

[Guest]

Where is the WRKGADM.EXE file located in Access 2003, I did a search on the
users PC and I can find it

 

[Guest]

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.

 

[Guest]

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?

 

[Rick Brandt]

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.

 

[Guest]

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

 

[Rick Brandt]

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.

 

[Guest]

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.

 

[Guest]

I stand corrected, its a join

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]

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]

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.

 

[Guest]

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.

 

[Rick Brandt]

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.

 

[Joan Wild]

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.

 

[David W. Fenton]

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.

 

[Rick Brandt]

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?

 

[David W. Fenton]

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?

We were getting locking issues in the LDB file of the workgroup
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).

 

[David W. Fenton]

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.

BTW, the situation in which I copy down the workgroup file with each
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).