Workgroups (97)

Topic

New Reply

I think I have set up a workgroup on a large company network, but I don’t see what I have acheived by doing so. Other users- not in the workgroup- are still able to access and change the database- even while I am in it. So I guess I have two questions- 1) how do I know whether or not I successfully set up a workgroup, and 2) if I did set up a workgroup, what have I acheived? Is the workgroup only used so that I can in the future set up passwords? Or is there other functionality that I am missing? I am thinking that I should look in the System.mdw file, but what then? I’m guessing that I did not really set up a workgroup, and made a mistake somewhere along the way. Help? Thanks!

Reply | Quote

Replies

If you’ve successfully set up workgroup security, you won’t be able to use the database without the correct workgroup and everyone will need an id and password to open the database.

However, you need to be careful how you set up workgroup security – it is not as obvious as it looks. See http://support.microsoft.com/support/acces…tent/secfaq.asp%5B/url%5D for details on setting workgroup security up correctly.

Reply | Quote

DM,
Thanks for your response. The thing is, we don’t think that we need passwords, since the database is of minimal sensitivity. It’s just that we had record integrity concerns…. in the situation that multiple users are in the database, we were concerned about record integrity. We were under the impression that a workgroup was necessary to allay these concerns, so I put the database (.mdb) on a shared drive, then copied the system.mdw file to the same sub-directory, then had one person join the workgroup. Another person was able to get into the database- since it is on an unsecured shared drive, and change records. Further, this other person (not in the workgroup) could do it, even when I (in the work group) had the database open. So it seems that we did not really accomplish anything, besides putting the database out onto a shared drive, as opposed to the private drive where I developed it.
I looked over the linked material, and a book I have, and it now appears that the workgroup has no functionality without password security being added- which we do not feel is necessary.
However, I would like to make sure that I did create a workgroup, and the system.mdw file does not give me a clue- I thought that myself and the other person in the workgroup would somehow be registered, but I don’t see that that is the case.

I can’t help but wonder if I am missing the big picture. On a network with a shared drive, without passwords, does the workgroup designation really add any functionality, either security or data integrity, and how can I view the workgroup members?
Thanks again. Dr Spyro

Reply | Quote

Every database created in Access has an Admin group and an Admin user. If you don’t remove permissions from the Admin user anyone with Access can open your database. Don’t forget to make yourself a member of the Admin group.

Reply | Quote

If you don’t remove permissions from the Admin user anyone with Access can open your database.

I hate to ask this question, but I will, “How do I remove permissions” from the Admin user?”

Reply | Quote

OK, I figured out how to do that. Now we are going to test to see that others are excluded.

Reply | Quote

If you don’t have login, how is anyone going to log in as anything but the Admin user … from which you’ve just tried to remove all permissions? BTW, it isn’t enough to remove the Admin users permissions, you have to move the Admin user out of the Admins group. Otherwise, they can go right back in and give themselves permissions. Of course, if you do move the Admin user, you’re right back to the problem of needing logins to have any permissions to the database.

Reply | Quote

I’m lost. OK- Lets go back to square one. What are workgroups good for?

Is it only for security, or does it involve file-sharing protocol, too?

Reply | Quote

“File-sharing protocol”? What exactly do you mean by that? Workgroups in the Access sense are part of Access security. That’s all they’re for.

Reply | Quote

Thanks for helping out. We are on a large corporation network, and put the database out on a shared drive, and so everyone had access to the database. Security concerns are minimal, and though we considered password protection, we didn’t feel it was necessary. However, we were concerned about situations where different users could be in the same record, and conflicts might arise. Reading through the material that I have- Access help books, it did seem that workgroups provided a more orderly resolution of these types of conflicts.

The database, which is conceptually very simple, really just an electronic file cabinet, will be used extensively by eight different people, and we were concerned that records had a potential to be corrupted in the case (inevitable) when multiple users were entering or querying data.

The minimum solution was to put the database on a drive where all users could get to it, after setting the file-sharing options appropriately (exclusive, conservative). The maximum solution would be to password protect the database. We believed that the workgroup solution was a compromise, in that it maintained exclusivity to the appropriate users without necessarily requiring the passwords. However, as I read through the responses to my original posting, it appears that this is not the case. It appears that the workgroup really added nothing that simply putting the database on a shared file would have accomplished, and that setting up the workgroup is merely a start to password- protection. Is this current understanding correct?

By the way, I thank everyone who has helped shed some light on the question, and particularly to Charlotte for her follow-up question.
Dr Spyro

Reply | Quote

Workgroup files are used to limit access to an mdb file so that unauthorized users cannot alter data or change design of objects. They have nothing to do with record locking, which I believe is your main concern. To learn about how to handle record locking in a multiuser environment go to the online help and type in “record” in the index. This will take you to the record locking subject. Click on display and you will see subtopics the first of which is “About choosing a record-locking strategy in a multiuser environment”. This should fully explain the options available to you and how to put them into use.

Reply | Quote

There is all kinds of other fun stuff that needs to be done to secure your database. Stuff like after creating the .mdw creating the database under the new .mdw. Joining the Admins group. Passwords. Removing permissions from the Admin user ONLY after you have joined the Admins group.

Go to ftp://ftp.microsoft.com/softlib/mslfiles/secfaq.exe and download the Security Faq. It details Access security.

Also, don’t make the mistake of replacing the standard system.mdw on your machine found in /windows/system or in WinNt/system with the secured one or ALL your Access apps on that machine will require you to logon. Put it elsewhere and preferably call it somethingelse.mdw

Practice on a copy of your original database first. I locked myself out of a couple of databases before I got a handle on Access security.

Reply | Quote