Solved Lock or hide Tbl,Qry,Frm&Rpt

kavehrad

New member
Local time
Today, 09:05
Joined
Jun 14, 2020
Messages
17
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
 
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.
 
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.
 
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.
 
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, 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.
 

Users who are viewing this thread

Back
Top Bottom