Table security

[Ixtreme]

I have an Access 2003 database. On a form a user can select values by
means of a combobox. If the user enters a value that is not present in
the underlying table, the 'on not in list' event asks the user if he/
she would like to add the new entry to the table. If the user answers
yes, a password form will be displayed asking the user for a password.
If the password is correct, the new entry will be added to the table.
However, the user could also bypass this by simply select the table
and add the new entry manually. How do I prevent the user from doing
that? Is there a way to force the user to always add new entries to a
table throught the form?

 

[Jeff Boyce]

How is it that the user can "see"/get to the table?

How does the user know which table to add the record to?

One approach might be to hide the database window and only present forms to
the user.

Another might be to "hide" the tables.

Good luck!

Regards

Jeff Boyce
Microsoft Access MVP

--
Disclaimer: This author may have received products and services mentioned
in this post. Mention and/or description of a product or service herein
does not constitute endorsement thereof.

Any code or pseudocode included in this post is offered "as is", with no
guarantee as to suitability.

You can thank the FTC of the USA for making this disclaimer
possible/necessary.

 

[Jerry Whittle]

You need to implement User Level Security. That way you can restrict user to
certain forms and reports plus not allow them to even see the tables.

However this is a LOT of work both to set up and maintain. Unless you have a
very valid requirement, such as HIPPA or some other law, to keep users out of
the table, I suggest that you don't sweat the small stuff and allow users
access to things. Just keep frequent backups.

 

[Ixtreme]

How is it that the user can "see"/get to the table?

I am not sure what you mean. But he can just go to the tables,
reports, queries etc by just minimizing the active form.

How does the user know which table to add the record to?

It's more like that I don't want the unauthorized user to add records
to certain tables. Only an administrator should be able to add
records. For example: a combobox contains a predefined list of
Officers. I don't want each user to add new records for the same
person eg. J. White, Jimmy White, J White.

One approach might be to hide the database window and only present forms to
the user.

Via Tools, Startup? But that can easily be changed by the user right?

Another might be to "hide" the tables.

How do I do that? in VBA? Could you please explain in more detail?

 

[Ixtreme]

You need to implement User Level Security. That way you can restrict user to
certain forms and reports plus not allow them to even see the tables.

However this is a LOT of work both to set up and maintain. Unless you have a
very valid requirement, such as HIPPA or some other law, to keep users out of
the table, I suggest that you don't sweat the small stuff and allow users
access to things. Just keep frequent backups.

I read the stories about user level security and I must say I am not
very keen on that option. The database is used within a risk
management department. Some comboboxes are restricted to certain
values eg Obligations. I don't want the user to add values by
themselves.

 

[Jeff Boyce]

You can disable the database window, the shortcut (right-click) menus, etc.
via the Startup settings.

You can remove the "X" (close this form/window) and maximize the form on the
screen.

If you let the users get "behind" the forms, you better be darned sure they
understand relational database design and the tips/tricks of using Access.
Otherwise, you lead them to believe that tables are just like spreadsheets,
and that they can type anything anywhere.

That's the reason Access offers forms, so you can direct/control what users
see and how they enter/edit data.

Good luck!

Regards

Jeff Boyce
Microsoft Access MVP

--
Disclaimer: This author may have received products and services mentioned
in this post. Mention and/or description of a product or service herein
does not constitute endorsement thereof.

Any code or pseudocode included in this post is offered "as is", with no
guarantee as to suitability.

You can thank the FTC of the USA for making this disclaimer
possible/necessary.