Re: access 2003

Is there a text version of the options regarding implementing system
security in access 2003. I assumed the best plan is to load the
converted or new databases (data & program) then set up the
security. The data will go on the server and the program database
will go on each workstation. IE, administorator and user with login
and password or just not allow changes on the forms, queries, reports,
etc and forget the login password, etc. Suggestions or pointing me
toward text to read will be greatly appreciated. There is a lot of
material available but nothing replaces experience.

I have found that setting up user-level security is complex because there is
so much to know and, sometimes, things don't work the way you expect them
to. If you unwittingly omit a crucial piece of the jigsaw, you can
compromise your security plan.

I seem to remember being caught out when Microsoft changed the security
system between Access 97 and Access 2000. If I remember right, in Access 97,
you can apply user-level security to modules (to prevent users getting into
modules) but, in Access 2000, user-level security doesn't work for modules.
I thought this was a pretty ghastly change for Microsoft to have made. I
hadn't noticed the change and, as a consequence, when I upgraded a secured
database from Access 97 to Access 2000, my code, which I had understood was
secure in Access 97, simply became insecure in Access 2000 without warning.
I would still prefer to be able to secure modules using user-level security,
than the alternative of creating an mde file. You may be confronted with
this issue. Check the Access 97 version of the database and see if the
modules have user-level security implemented. If they did, then you're going
to have a nice time sorting out how to implement security on the modules in
Access 2003 (remembering that the file format is Access 2000 for your
current database).

I would qualify the following comment by saying that, as always, my
information may be out-of-date (as I don't use Access 2003). However, I
think that, the only current way to make modules secure is to compile the
database to create an mde file. If your code modules are in the Program
database, then at least your Program database should be converted to an mde
file (assuming you need to secure the code modules from user interference).

However, creating MDE files has a number of implications, which may put you
off this approach. For example, you absolutely MUST keep the mdb version in
order to do further development work and you must compile any new mdb
version and release it as an mde version to the users. I believe an mde
version will not allow changes to forms and reports by the user. This is
because the code behind the forms and reports (as well as code in any
modules) has been compiled. This means that, in the mde version of the
database, all program text you write in the VBA editor has been removed from
the database and all your programs have been converted to a (kind of)
machine code. Therefore, even you cannot change the programming in the mde
version. This could be significant if your present database deliberately
allows users to change forms or reports, or if the code in your present
database changes the design of forms or reports at run-time to meet
different situations.

I've created one database in the past with serious user-level security. Like
you, initially, I set up security manually, which took a lot of effort.
However, I ended up using VBA to program the security, which took even more
effort! I seem to recall I did this because it was too easy to overlook
something when doing things manually. When I did things manually (in Access
97), I documented every single database object - tables, queries, forms,
reports and modules - and the permissions I had given to each object. In
fact, I gave different permissions to a number of different groups and made
users members of appropriate groups depending on what access to the
database they should have. I had a limited number of generic user names so
they didn't keep changing as time went by. I documented all permissions to
database objects, groups and users. It took ages and ages. Most important of
all, I wrote down all the security information I used when creating the MDW
file (the workgroup admin file) and kept the written record safe. The MDW
file is the key that unlocks the database. If you lose the key (say the MDW
file gets trashed), then you must restore a backup MDW file or recreate the
MDW file from the written record. If you plan to use the existing MDW file,
then my advice is to keep several copies of it very safe, both on- and
off-site. This is a big subject, so give yourself plenty of time - or the
frustration will drive you nuts!

As requested, here are a few suggestions for learning texts:

1. The book I originally used was:
"Microsoft Access 97 Developer's Handbook"
by Timothy M. O'Brien, Steven J. Pogge, and Geoffrey E. White
ISBN 1-57231-358-7
Publisher: Microsoft Press
Despite a number of minor errors (which most computer books have and which
you, the reader, will easily spot), I still very much admire the consistent
and clear language style of this book. They must have had a very good
editor. The book gives concise and clear explanations of a good selection of
topics, including DAO security. I imagine the book is out-of-print - but you
could search the Intenet (eg Amazon) and see what comes up. A bookseller
somewhere might still have a copy.

2. The other book I mostly use these days (but there is a more up-to-date
version now) is:
"Access 2000 Developer's Handbook"
"Volume 1: Desktop Edition"
by Ken Getz, Paul Litwin, Mike Gilbert
ISBN 0-7821-2370-8
Publisher: Sybex
There is a "Volume 2, Enterprise edition", and a "VBA Language Reference"
book. I bought all three books as a package at a reduced price. These books
are clear, authoritative and indefatigable in their explanations. These
books will set you back quite a bit, so I recommend you browse them in a
good computer bookstore before buying to see if you feel comfortable with
them. (They are much cheaper than a computer course and it's great to have a
good permanent reference on your bookshelf.) Check out the authors' website:

http://www.developershandbook.com/

The above website suggests that the book has been updated for Access 2002,
but not yet for Access 2003. Double-check with a bookstore.

3. You could search the Microsoft website to see what papers on security
you can find there.


I wish you the very best of luck for your journey through the quagmire of
vast, new and changing knowledge.

Regards
Geoff

Why French?
You used "Prive" for "Private".



.

Relevant Pages

  • Re: MDE
    ... - You are using the incorrect MDW file used to secure the database. ... MDE open or not) select teh menu option Tools> Security> User and Group ... if you don't see the other User Accounts you created when the ...
    (microsoft.public.access.security)
  • Re: Whos in the .ldb first?
    ... If the .mdw file you secured the database with isn't there, ... good indication that your security wasn't set up correctly. ... >>have full permissions on the FOLDER that the database is ...
    (microsoft.public.access.security)
  • Re: security not requesting log in
    ... If you had done this, then no matter what mdw file she used, ... Another step you should have performed is to secure the database file. ... and delete all the security files and create a new file. ... opens immediately to the main screen and shows her as Admin. ...
    (microsoft.public.access.security)
  • Re: security not requesting log in
    ... If you had done this, then no matter what mdw file she used, ... Another step you should have performed is to secure the database file. ... and delete all the security files and create a new file. ... opens immediately to the main screen and shows her as Admin. ...
    (microsoft.public.access.security)
  • Re: setting a password on a button on the switchboard
    ... Could you send me the sample database for the fourth option (4. ... > Security in an Access database can probably be broken down into two big ... > points about being easier than User Level Security, ... > What type of data are you trying to protect? ...
    (microsoft.public.access.forms)