Access 2003 security warnings

  • Thread starter Thread starter Richard Harison
  • Start date Start date
R

Richard Harison

Hello,
One client, running Access 2003, has noted that every time my database starts,
she gets a "this file may not be safe..." message.
My few other clients, running both 2002 and 2003 have had no such problem. The
program was developed in Access 2002.
Short of buying a digital signature for $431/year (ouch--I am a very small
operation), what can I do to help her. Access 2002 seems not to have a macro
security level like Excel (at least I can't find it)--maybe it's in 2003. Even
if so, I am reluctant to tell her to set it on low.
My program contains many macros and extensive VBA code. Any ideas? Thanks
 
Richard said:
Hello,
One client, running Access 2003, has noted that every time my
database starts, she gets a "this file may not be safe..." message.
My few other clients, running both 2002 and 2003 have had no such
problem. The program was developed in Access 2002.
Short of buying a digital signature for $431/year (ouch--I am a very
small operation), what can I do to help her. Access 2002 seems not
to have a macro security level like Excel (at least I can't find
it)--maybe it's in 2003. Even if so, I am reluctant to tell her to
set it on low.
Click to expand...

Why? The macro security first appeared in Access in 2003, so you won't find
it in 2002. I would tell her to set the macro security to low. It's no
more dangerous than running the mdb in 2002. When was the last time you
heard of malicious code being run in a mdb?
 
Thank you Joan!
I will forward your recommendation. Your logic is well taken--2002 is then
theoretically "wide open " to the attack you describe as virtually
non-existent.
Since I do not run 2003, perhaps you could tell me where the macro security
level set is. Is it in Tools>Options>Security Tab like Excel? Or is it in
Tools>Security, where all the permission stuff is?
Thanks again!
 
It's in Tools>Macro>Security

It's possible that 'security' isn't showing on the machine. If that
happens, just reset the menu bar in Toolbars, Customize - select the Menu
Bar and hit Reset.
 
Thank you, Joan
Everything is resolved!
I had one additional thought. Security, it seems to me, lies in 2 different
areas.
1) hacking from without
2) hacking from within
As far as #1 goes-- there is no doubt these people trust my macros and code
As far as #2---well there could (highly unlikely) merry pranksters within the
organization, but I have a password on all my VBA code. Additionally, they get
an MDE file--where all the code is compiled anyway.
So were I to convert all the 20 or so macros to VBA, would that not be
internally bulletproof?
Thanks again
 
Bullet-proof- no. You should also realize that they'd get the security
warnings with any code (despite its name it isn't related to macros).

Security in Access is a misnomer. It really is about putting up roadblocks.
Making a MDE is a good idea - that'll keep them from changing the design of
forms/reports/modules. It doesn't protect the tables/queries.

You can lock down the mdb files so that people can't get to the database
window. You can create custom menus/toolbars for use throughout your
application.
Create a startup form (a main menu form if you have one) that is opened on
startup. Use the features in Tools, Startup to set the startup form, set
your default menu (the custom one you made), disable all the checkboxes
about allowing built in menus, toolbars, changes etc. Hide the db window
(ensure the custom menu you create does not include the Windows, Unhide
item); and uncheck the allow special keys (this will disable the F11 key,
among others)

If you need to bypass these startup features, you can hold the shift key
down while you open the db. If you feel that your users may use this to
bypass your settings, you can disable the shift key bypass - there's an
example in help for doing this(look for AllowBypassKey) or at
http://www.mvps.org/access/modules/mdl0011.htm
and
http://www.mvps.org/access/general/gen0040.htm

Your database should be split. You can put an autoexec macro on the backend
that throws up a message telling them to use the application, and then
quits. Disable the shiftkeybypass in it too.

These additional things are likely to be sufficient. If you have users that
are trying to bypass all of this, then I think your organization has other
problems.
 
Thank you, Joan...
Quite a list, but it all makes sense. My database is already split, so I am at
least that far.
Thanks again...I'll keep all of this in my files!
 
Back
Top