"It works beautifully on my PC, but my test users are able to open the database with no prompt for UID and P/W."
What this tells me is that you didn't realize you have to create a secure workgroup file in order to truly limit access to your secured database. This is a very common mistake made by people using Access security. Some folks don't even realize the huge hole they have in their security.
The Access security model is always "turned on". But since it's a consumer product, Microsoft didn't want the security to be obtrusive, so what they did was provide a default "open" workgroup file as part of every installation of Access. If you use that workgroup file to implement security, you can get it to work fine--but anybody who has a copy of the original, unmodified workgroup (set up with the same workgroup id and organization name) has "open" access to your database.
To block this, you have to create a secured workgroup file, one that contains a different, secret workgroup id. When you do that, and then set up your users and groups and permissions in the database, the user permissions in the database will be associated with the secured workgroup. They won't work with the default workgroup any more.
In your case, you already have permissions in the database for the default workgroup, so first you have to remove all the permissions you put in with it. After you've done that, I recommend using the User-Level Security Wizard. If you're using Access 97, read up on the security features in the help file, and follow the instructions in the wizard very carefully. The Access 2000 wizard is much more bulletproof.
Note (not something you'll find in the help file, unless you're very good at reading between the lines): When you're in the database looking at permissions, all you see is User and Group names. In fact, though, the permissions are associated with a security identifier which is generated from the user or group account and the secured workgroup id. Thus, a given user or group can have separate sets of permissions for different workgroup files. That's why you have to remove the permissions that were granted on the default workgroup, before you start adding permissions on the secured workgroup. If you don't, they'll still be able to use the permissions associated with the default workgroup.
Even when you use the wizard, you'll still need to read the docs. Because you're forcing your users to use a secured workgroup, and not the default workgroup installed with Access, one of two things has to happen before they can open your database. Either they have to "join" your secured workgroup (using the Workgroup Administrator), or you have to give them a shortcut that contains the /wrkgrp command line parameter, and they can only use that shortcut to start your database (as opposed to, say, opening Access and then opening your database within it). If they join your workgroup, they'll lose access to other databases until they finish and join the default workgroup again; some users won't like that. If they use your shortcut, they lose alternative methods of getting to your database; other users won't like that. You'll have to weigh the alternatives in your particular environment, pick an alternative, and train the users one way or the other. I usually prefer the desktop shortcut method myself. Rick Sprague
