Deltic,
A couple of points.
1. You should never (NEVER) allow users to access the raw data in your
database directly. In a multi-user environment, you should split your data
(commonly referred to as a back-end) and your application (commonly referred
to as the front-end) into two parts; Access provides a wizard for doing this.
This will put your tables in the back-end, and leave your forms, queries,
reports, macros, and code in the front-end.
a. The wizard will also link the tables from the back-end to the
front-end. I usually delete all the links, move the back-end to a network a
network folder that all of my users will have read/write access to, and then
relink the tables to the front-end. I do not tell the users where the
backend data resides and have even gone so far as to change the file
extension to .txt to confuse people that might wander into the folder.
b. Each user should have their own copy of the front-end, located on
their desktop. You can use an application like Tony Toew's
AutoFrontEndUpdater to update this application whenever you make changes.
2. When you distribute your front-end uncheck the option that allows the
user to use the Access Special keys. This will prevent them from opening the
application while holding down the shift key (which would bypass the startup
form and give them direct access to the forms, reports, and linked tables).
3. Because I hate settingup and maintaining workgroup security (and because
it is not supported in 2007), I have been adding a Users table to each of my
applications for 5-6 years now. The table contains the windows userid of all
the authorized users along with other info including their email address.
Then, in the startup form of the application, I check to see whether the
Windows userid of the individual running the application is in the Users
table. If not, I display a message, usually offer them the opportunity to
request access by sending an email to the application administrator, and then
Quit the application. If they are a valid user, then I display the startup
form.
4. These steps don't prevent someone from sitting down at someone elses
computer, and using the application, but good workplace security measures
like setting the screen saver to come up after 10 minutes of inactivity, and
requiring people to lock their system when they step away prevent this.
5. If you will eventually have multiple applications to manage, setting up
a separate application/database for you to manage user application
permissions might be a good way to go. With this setup, you maintain a users
table, applications table, and UserApplications tables in a separate database
that only you or your system administrator has access to. You would use this
application to indicate which applications each user would have access to,
and instead of looking in each applications back-end for user permissions,
your applications would look in this database. You could also identify user
roles (tbl_Roles, tbl_User_Application_Roles) in this database for control of
what aspects of a given application a user has access to. This is similar to
the security model provided by SQL Server.
--
HTH
Dale
email address is invalid
Please reply to newsgroup only.
