Bypass Security Warnings in Access Runtime

[Guest]

How can I disable or bypass the security warnings about Unsafe Expressions,
and code warnings in an mdb that was packaged with Access Runtime using the
Package Wizard?

 

[Paul Overway]

You need to sign your application with a digital certificate or set macro
security to low. You can set macro security to low during install using the
following settings in PDW:

Root=Local Machine
Key=SOFTWARE\Microsoft\Jet\4.0\Engines
Name=SandBoxMode
Value=#00000002

Root=Local Machine
Key=Software\Microsoft\Office\11.0\Access\Security
Name=Level
Value=#00000001

 

[TC]

You need to sign your application with a digital certificate or set macro
security to low.

Why does everyone keep saying this?

By far the easiest way is to start the database via a script file which
sets the macro security level to low for that single invocation of
Access. This does not require a certificate, or a registry change, and
it does not affect any other database(s) - just the one being started
by that script.

Eg. in VBScript:

dim o
set o=createobject ("Access.Application")
o.automationsecurity=1 ' set macro security LOW.
o.opencurrentdatabase "full path to your database"
o.usercontrol=true
set o=nothing

I've never packaged a system with the Access Runtime, but surely it
should be possible to set it to start the system by running a script?
HTH,
TC

 

[Paul Overway]

Scripting may also cause prompts...from AV software.

 

[TC]

True enough. But certificates can also stop working & the prompts
reappear.

For example I *think* that modifying a query (programatically) will
break the signed status. (Can you confirm one way or the other?)

I've also wondered whether *compiling* a query (ie. when it is run the
first time after creating or modifying it) would also do that. Yes? No?

TC

 

[Paul Overway]

I've seen enough comments about the signed status being broken (like Scott's
post of yesterday), that I'll continue to shy away from macro security until
they fix it. Which is why my installer sets it to low. So, I've had no
complaints from 2003 users. For now, having macro security set to low is
the only way to be sure that the user doesn't get prompts and false alarms.

There is even more that they fail to tell you about getting a certificate
though....i.e., they "recommend" that you spend even more money to sign up
with Dunn & Bradstreet. And if you don't, odds are you won't get a
certificate or it will be for you as an individual only. Even if you do
sign up with D & B, you're not guaranteed to get a company cert. And then
guess who is liable? You, not your company. It really is a crock.

You might be right about the query issues, but I haven't verified it myself.
It should be easy enough to test the conditions you cited, even with a
selfcert certificate.

 

[TC]

Paul Overway wrote:

(snip good info)

You might be right about the query issues, but I haven't verified it myself.
It should be easy enough to test the conditions you cited, even with a
selfcert certificate.

Unfortunately I can't do that, because I am still developing on the
lowest common denominator platform of A97 & W98

I'd be interested if anyone else could confirm it.
* Does modifying a query's SQL (through code at runtime), break the
digital signature?
* Does *compiling* an uncompiled query break the digital signature?
Cheers,
TC