Hi everybody,
It seems users can bypass every effort I make to hide the DB window from
them just by simply holding down the shift key!
1.Are there any other ways(besides this one) they can make the DB window
visible?
2.Is there any way to make sure that my users can "never" view the DB
window,I want to shut out every possible way for them,just so I am sure
that in case of a problem I am 100% certain that nobody messed with the
aplication through the DB window!
Thanks in advance!
What you can do is add layers of barriers. Some barriers will only stop
people with almost zero knowledge of Access while others are more
robust. There are no "100%" barriers if the person you are trying to
impede is knowledgeable enough about Access and determined enough to
spend some time breaking in.
Much of this is affected by *what* you are trying to keep people away
from. Do you want to keep them away from the data or from the design of
the interface? If the latter, do you only want to prevent them from
messing with it or do you want to prevent them from even looking at it?
The fact that you ask this question indicates that your own Access
familiarity is fairly low. You could very well have users that know more
about Access than you do. Those people will be harder to lock out than
others that might not have ever opened Access until they were given your
app. That group will probably never even find out about the shift-key.
As is usually the case, you can block 90% of the people with 10% of the
effort expended on your part. The remaining 10% involve much more work
from you.
It is easiest to protect the interface. You can protect that from both
modification and viewing simply by giving your users an MDE copy of your
file instead of an MDB. An MDE has all source code removed and all code-
based objects (forms, reports, modules) can neither be viewed in design
mode nor have any part of their design altered. You keep the original
MDB for yourself to continue to work on for future changes.
The above can only be deployed properly if your app is split. One file
for data only (shared on the network) and another with everything else.
The second file contains links to the first and you give each user their
own separate *and local* copy of this second file.
If protecting the interface is your only concern then you really don't
need to worry about the shift key since the db window will still not give
them design access to any of your interface objects. If you prefer
though, there is code you can run (one time) on the file you give your
users that disables the shift-key. Google these groups for "disable by-
pass key" and you should find examples of this code. Of course, a minor
change to that code will re-enable the shift key and some of your users
might know that.
Protecting access to the *data* is much harder. The best you can do in
that regard with an MDB storing your data is Access User Level Security.
It is an advanced topic and the majority of those that attempt it get it
wrong the first few tries. This definitely falls into the category where
the developer expends a LOT of effort to block most of the last remaining
percent or two of users. This allows you to have pretty fine control
over data access. You can for example deny access to tables/queries
except through your forms and reports. You can also deny certain users
access to certain forms/reports while allowing others. Another thing ULS
provides is the ability to disable the shift key such that you have to be
an admin user to re-enable it. That code is slightly different, but
again should be easily located with a web search.
ULS is not 100% secure because there are utilities and services on the
Internet which can get past it. It is not even supported any longer in
the newest file format (AccDB) that can be used in Access 2007. 2007 can
still use it if you stay with the MDB file format.
Below ULS is "security through obscurity". You can hide all of the links
to your tables in the file you give your users. If they happen to get to
the db window they would see nothing. That is of course unless they know
how to enable "view hidden objects" in options.
You can prefix all link names with "USys" which also hides them in the db
window. That is unless the user knows how to enable "view system objects"
in options.
You an create all of your links in code upon startup and delete them at
application close. This would do nothing to keep users from them while
your app is opened and you cannot guarantee that the delete-on-close code
will even run (depending on how the close occurs).
You can make the network share where the data resides hidden (though
users must have permissions to it). That at least makes it difficult for
users to simply browse to it in Explorer.
This is not a complete listing, but as you can see, nothing is absolutely
safe as long as your data is in a Jet (mdb) file. For real data security
you need to use a server back end (SQL Server, Oracle, etc.). These can
be used with an Access file for the interface and this is how many
developers use Access.
