Access 2003 Security Warning

  • Thread starter Thread starter moondaddy
  • Start date Start date
M

moondaddy

I just installed Office 2003 and when I opened up an access application I
got the warning msg: "Security Warning: Unsafe expressions are not
blocked.".

This application has over 200,000 lines of code and there's no way I can
re-write it to get around the vba code that's v.2003 declares unsafe. This
app runs in a controlled environment and we're not concerned about the code
in this app. Is there any way to prevent the msg from popping up every time
a user opens the app? It doesn't do anything to help the client's
confidence in the application and is a down-right nuisance.
 
Hello,

Thanks for your post. When you first start Microsoft Access 2003, you will
see a dialog that prompts you to install the Jet 4.0 SP8 update. It will
also indicate that unsafe expressions are not blocked. The Jet 4.0 SP8
update allows you to block unsafe functions from running in your database
that can modify the settings on your computer. The Jet 4.0 SP8 update
turns on a registry entry called SandboxMode, which will block unsafe
functions such as KILL and DELETE from running in macros or queries.

With Access 2003, SandboxMode is handled by the new Macro Security Levels
under Tools, Macro, Security. By default, in Access 2003, the macro
security level is automatically set to Medium. Setting the value to Medium
or High automatically turns SandboxMode on, setting the registry value to
3, the most secure. When the macro security level is set to Medium or
High, when users try to open a database file, they will see a dialog that
warns that the file may not be safe. This warning appears for your
protection. This functionality has been added by design
in Access 2003.

To turn this warning off, you can go to Tools, Macro, Security, and set the
security level to Low. This however is not recommended, as it will leave
your database vulnerable to running potentially unsafe expressions. To
help protect against macro viruses, it is recommended that you run
antivirus software, set the macro security level to Medium or High, and use
digital signatures so that you know you are opening a database file that
you can trust.

For more information about macro security, you can view the Help topic,
"About helping protect files from macro viruses."

If you go to Tools, Macro, and the Security menu is not there, to add the
security menu, right-click on the menu bar, choose Customize. Highlight
the menu bar tool bar. Click the Reset button. Now close Access and reopen
it. You should now see Security under Tools, Macro.

Please feel free to post in the group if this solves your problem or if you
would like further assistance.

Regards,

Michael Shao
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
 
Thanks for that detailed information.

I think this issue will be a big source of confusion for everyone. There is
no way that small developers will be wiling to purchase a digital certifcate
to sign their products. (Anyway, if their products do things like change
stored queries "on the fly", this will break the signing, anyway!)

So small developers will be forced to advise all of their customers, to set
macros security to Low. This will be the >reverse< of the affect that
Microsoft presumable wanted :-(

TC
 
Hear Hear

Have just read the postings on this and am a bit
perplexed, Access was supposed to be for small - Medium
sized folks wanting the ability to build complex apps
without huge budgets. Our app is only run on our local
network and is continuosly developed, certificates are
therefore not appropriate.

Any suggestions how a simple application sending an email
via VBA code within the Access Database using an outlook
object can avoid the security warnings, so far I have
recieved advice that we need to write a com addin, apart
from this being a little out there for a simple access
programmer why would access have code that allows you to
send an email automatcially and then need someone to
manually authorise it ?
 
As for the >Access< macro warnings, I gather that the >recipient< of the
application (not the supplier or developer) can "self sign" the application,
to stop the warnings happening. But: (1) most recipients will have no clue
how to do that, and (2) if your application does certain things like,
changing the SQL of a stroed query "on the fly", this breaks the signing, &
the warnings start to happen again!

So the only reasonable approach that I can see, for a small developer or
in-house product, is to advise the recipient to change their macro security
to LOW. This is probably the >reverse< of the affect that Micosoft intended
to occur. So much for poorly-thought-out changes!

As for the >Outlook< warnings, they are a different issue entirely. One
solution is to use a seperate component to send emails directly from VBA,
without relying on >any< email program on the user's PC. Then msoft can add
whatever Outlook warnings they want!

Cheers,
TC
 
Back
Top