Solved Lock or hide Tbl,Qry,Frm&Rpt

[kavehrad]

Hi everyone!
Is there a way to lock or hide tables,qeries,forms & reports so user can not see them or change the designs?

Thanks

 

[theDBguy]

Hi. Forms and reports, you can protect from design changes. Unfortunately, that's not possible for tables or queries. You can try to hide them, maybe that will be enough for some of your users.

 

[Isaac]

A couple other things that came to my mind were to deploy an accdr (simply changed .accdb to .accdr), or else to actually use the Access Runtime. These are just a couple more things on a list of options that stop short of foolproof security (to most people's minds), but do go a ways towards it.

 

[Deleted member 147267]

Isn't the standard answer to distribute accde, hide nav pane, disable bypass and maybe disable ribbon? Even if a user can get past that, in accde you can look at query sql view only, and cannot see report, form, query or module design.

 

[The_Doc_Man]

Is there a way to lock or hide tables,qeries,forms & reports so user can not see them or change the designs?

The basic answer is "No" - but you can make it more difficult. The question is WHY you want to do that? If this is a commercial product and you want to protect it then the .ACCDR and Access Runtime solution is probably better. If this is just an in-house tool and you fear that folks will diddle with it too much, then an .ACCDE might be enough. But if it is strictly in-house, the best solution is to have the boss who wanted this Access solution to his problem to issue a "heads will roll" decree.

Access is not designed for maximum security because it was originally designed for small businesses that would not have excessive security needs. If you really worry about security of tables and queries, you need a more secure back end such as SQL Server or other active SQL back end engines, then use a front end that doesn't expose much.

You are going to have to decide just how tight you need to make it and recognize that the tighter the security, the harder it will be to implement it. AND if you have an ongoing product (meaning that you have to implement "fixes" down the road on a regular bases), you need to keep open a way to provide the updates. It is always a balancing act between how much YOU are willing to put in someone's way and how badly they want to get to what you are protecting.

 

[Isaac]

the best solution is to have the boss who wanted this Access solution to his problem to issue a "heads will roll" decree.

Love it

 

[The_Doc_Man]

Isaac, it is all about motivation. You tie the sanctity of the DB to the sanctity of someone's job and people listen. We had this situation in the Navy Enterprise Data Center where I worked. However, fortunately for those hard-heads, we were a land-based (headquarters) unit so keelhauling wasn't available as a punishment.

 

[isladogs]

For a detailed explanation of the various steps described by others above, see this two part article
Improve Security in Access databases

 

[Pat Hartman]

For starters, your app should open to a menu and all interaction with users should be via that menu. Users only see Forms and Reports. Users should NEVER, EVER even see the navigation pane.

As the others have said, this position is difficult to enforce but if you never show people these things, they won't go poking around. Also, if you use one of the suggested distribution methods that distributes a new copy of the FE each time the app opens, anything that gets broken will get fixed simply by closing and reopening the app.

Even an .accde can be renamed to .accdr and I do that also. The idea of the .accdr extension is that it tells Access to pretend to be the runtime engine so Access will never allow the user to see any object in design view as long as the db has .accdr as its extension. Of course a savvy user can simply rename the FE to have an .accdb extension and they're back in business but shush, don't tell anyone

 

[kavehrad]

Thanks for your answers