ps40,
There are a few confusing concepts in the security model here. If you go the Security route (which, if you're going to do some real-world Access projects, you should) then read on, otherwise the below paragraphs will be a bit confusing and overkill. But you should understand the difference between 'database password', 'password', and PID.
First thing is to forget about 'database password' completely. It's easily hackable and just plain confusing to most users.
Now, when you create a new user (hit F11 to focus the main db window, then use the Tools menu, then Security, then User & Group Accounts), you choose "New..." and add the user name in the upper textbox that is presented. The lower textbox is for PID, which is *not* a password, and you will most likely never need to use this value again. Remember or write it down, though, because if you lose your system.mdw (where this info is stored) you'll need this to recreate that user.
You can't create a password at this point, however. But make sure for the new user, if it's your new 'God' user, to add the Admins Group to his groups.
A bit about the PID field. It is only used internally by Access to create a hash value for the userid, ie. when Access checks permissions on an object, say a table or query, for the logged on user, Access never sees 'john' or 'guestuser' or whatever, instead it sees the userid as some gibberish created by some algorithm involving the userid and this PID, but you'll never ever need to know or deal with this value.
Now, the password is what is used to log the userid onto Access when you open the program--but you can't set the password until you logon as that user. This is sort of a catch-22, because you can't logon as that user unless you use a command line to open access via a shortcut (forget about that for now), or create a password for Admin user, which is who you'll be normall logged on as. So create an easy password for 'admin', usually just make it 'admin' or 'x' or something, because this user is going to be a user without many permissions, and you don't care about a difficult password for him.
So after you create admin password, the next time you open Access you'll be forced to enter a userid/password. So you log on as your new user, say, 'john', and *no* password, since you haven't created it yet. Now go into the Tools|Security|User & Group Accounts, and create the password.
Now you must create a new blank .mdb, (while logged on as 'john' or whatever your 'god' user is), and import all the objects from your existing database. Keep, but rename and save the old db. Now rename this new db to the orignal name, and you're ready to go in and strip all object permissions from the Admin User and Admins Group, same with 'User' user & groups. In the User & Group Permissions menu option, you can select the 'Object Type', and then use the Shift key to select all the objects in the 'object name' window, and then to remove all permissions, just uncheck 'read design', which unchecks all at once. But for each set of object types you select, you must do the same for Admin user Admins group, and also User user and User group. Then you'd typically, for each set of object types, give 'read' permissions, or 'open' (for forms, reports) and then test the db (while logged on as Admin) and add permissions as you see fit--which of course requires closing access and loggin back on as 'john' or whatever.
This seems like alot, but once you do it a few times, it will become much more understandable, and it's really the better way to go, in my opinion, rather than .mde (kludgey) or using database password, etc.
--Jim
