Own security

[SugarCOffee]

Hi!

I've made a database that is going to be used by different users. But now i wonder if its possible that I can put my own security fallbacks in it.
Like maybe he asks a password every 3 weeks or something, of maybe something that expires after some time. Antything! .

Thanks

 

[statsman]

It depends on the version of Access you are using.

The "built in" security function in Access will not allow this as you are required to log in each time. However, there have been several discussions lately that deal with customized security. These may permit it.

Do a search on "Security" which may enlighten you.

 

[Banana]

Statsman has given you a useful advice.

I'll offer this: It's actually easier to deceive yourself into thinking it secured than it is to actually secure it.

For this simple reason, I tend to shy away from custom solutions whenever possible and for where it's unavoidable, try to re-use as much as security that already exists somewhere. A good workaround is to simply use Windows filesystem permission. Since you can then configure the users' machine to require new password and grant only people who need access to the database by placing the file in an designated folder, this will do nicely in keeping out non-users and IMHO is far more effective than the Share-level password feature of Access.

On a similar token, Tom Van Stiphout, with help of Paul B. demonstrate implementing an access control using Active Directory in Access:
http://www.accesssecurityblog.com/

Note that implementing this technique is very handy for controlling what forms will be shown to which users, it does not actually protect the data and in that case, it's traditionally better to store the data in a server-based RDBMS unless you feel that Windows filesystem is sufficient and you can trust your users to be honest.

Good luck.

 

[SugarCOffee]

Thanks for the info .
Going to see what I can do now!

 

[Simon_MT]

Here is my advice which does go against the grain a little.

Putting in User driven security is a little protectionist and overstate the importance of the imformation. I had an experience with the Executive Payroll which we were not allowed to touch being left for all to see on a communal printer. It stayed there for almost a day with most of the entire staff making a pilgrimage to that printer.

So the lesson from that episode was no matter how much security you put into a system, printed reports can undermine those security measures.

Simon

 

[statsman]

A most interesting conversation I'm sure when the culpret was called into the boss's office.

 

[Galaxiom]

Access 2007 dropped the BuiltIn User security. No new design should use it.

Data that really matters should be on a database server where it can be properly managed.

With less critical data the goal is more about making sure users are presented with a interface that suits their needs as about protecting the data from view. Don't show what you don't need serves well to both keep people out and simplify their interactions with the system. Don't giive naive users too much power.

One way is to set a security level for each user. Then set a security level for each object down to buttons and boxes. The OnLoad event for forms and reports tests each object against the user security level and sets the enable, visible etc properties to match.

Otherwise a table can be maintained to record the enabled objects for each user. Anything that can be imagined can be achieved with carefully constructed tables of rights and creative VBA.

Good systems also control the ability of the user to View or Print a document. Printing is only made available to those who can be trusted not to leave it sitting on the printer. Indeed it is sensible to control which printers are available for particular reports as born out in Simons anecdote.