Macro Security

[Terry]

How do you give someone a database that does not require Macro Security to be
set to Low?

[Paul Overway]

You'd have to obtain a digital certificate and sign your project with it.
However, depending on the design of your app, the app may become invalid
during use anyway even if it is signed. So, until Microsoft fixes the mess,
you're best to set Macro Security to low.

--
Paul Overway
Logico Solutions
http://www.logico-solutions.com

"Terry" <Te...@discussions.microsoft.com> wrote in message
news:DF2BB186-67B2-4F34...@microsoft.com...

[TC]

Paul Overway wrote:
> You'd have to obtain a digital certificate and sign your project with
it.
> However, depending on the design of your app, the app may become
invalid
> during use anyway even if it is signed. So, until Microsoft fixes
the mess,
> you're best to set Macro Security to low.

Paul, I really wish you would add the other option (which you are well
aware of) to your standard reply.

For the original poster's benefit, the other option is to start the
database via a script file which suppresses macro security for that
single run, without affecting anything else. Eg. in VBScript:

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

HTH,
TC

[Paul Overway]

I don't mention it because IMO it really isn't a worthwhile option to
pursue. Many virus scanners alarm on any VB Script that is run...unless it
is digitally signed, which puts you back to getting a certificate. If
you're going to get a certificate, you might as well skip the VB script and
sign your app instead. Writing an exe to automate the code sample you
provided might make more sense.

--
Paul Overway
Logico Solutions
http://www.logico-solutions.com

"TC" <aatcbb...@yahoo.com> wrote in message
news:1108174269.3...@g14g2000cwa.googlegroups.com...

[Paul Overway]

Another issue with using the automation approach...whether from VB Script or
an exe, you can't instantiate the Access runtime. Your solution can only be
implemented with a retail version of Access installed.

--
Paul Overway
Logico Solutions
http://www.logico-solutions.com

"TC" <aatcbb...@yahoo.com> wrote in message
news:1108174269.3...@g14g2000cwa.googlegroups.com...
>

[TC]

I didn't know that (but I've never used the runtime). Why is it so? If
the runtime version has a ProgID (like "access.application"), shouldn't
it be possible to CreateObject it?

Cheers,
TC

[Paul Overway]

Microsoft deiberately disables automation in the runtime version...its been
that way forever. Probably another way to get people to buy retail version.
In any case, you'll get a 429 error if you try to instantiate it.

--
Paul Overway
Logico Solutions
http://www.logico-solutions.com

"TC" <aatcbb...@yahoo.com> wrote in message

news:1108187375.6...@l41g2000cwc.googlegroups.com...

[TC]

Paul Overway wrote:
> I don't mention it because IMO it really isn't a worthwhile option to

> pursue. Many virus scanners alarm on any VB Script that is run...

(snip)

Maybe. But all the PCs where I have installed my product, have active
virus scanners, and none of them has alarmed on the script (so far -
touch wood!)

I'm not saying that my approach *always* works. But it is false to say
that it *never* works. So, since it can be tested in about 5 minutes,
it clearly should be mentioned as a possible alternative method.

Suggesting to folks that they change their whole PC's macro security
level to Low, is not prudent advice, IMO. What if they then get a virus
which erases their hard disk, & would have been prevented at their
original security level?

They would certainly have an argument, for holding you partially
responsible. They relied on your professional advice, they did what you
suggested, then they suffered an unexpected adverse consequence.

Personally, I would not advise someone to reduce *any* security level
(macro or otherwise) on their PC, so that my application could run,
unless they signed a waiver which explained the possible consequences &
had them accept that risk.

Cheers,
TC

[TC]

Ok, thanks for the info.

Cause number 56,486,397 of error # 429!

TC

[Immanuel Sibero]

TC, Paul,

I just read this. Thanks for the interesting and very informative thread.

So I take this to mean that if I have only runtime Access installed on a
machine, I can not automate Access at all (from Excel, Word, etc.)??

If so, now that I think about it, it does make sense for MS to deliberately
disable automation in the runtime version. Having a runtime version only
obviously means that you dont have the product (Access) itself installed.
Since you dont have the product installed, you shouldnt be able to automate
it. Just like you cant automate Outlook if you dont have Outlook installed.

Immanuel Sibero

"TC" <aatcbb...@yahoo.com> wrote in message

news:1108188532.1...@c13g2000cwb.googlegroups.com...

[TC]

Hi Immanuel

I can imagine the surprise when someone implements an integrated Ofice
solution where everything automates everything else - then deploys it
to a runtime-only environment! Oops!!

I made the decision long ago, to have nothing to do with the runtime
version. My product states on its label, that the user must have a
working, retail copy of MS Access version xm y or z. When I made that
decision, I was unsure whether it would cause me grief. But it has not,
so far - touch wood!

As for the macro security thing, the approach I suggested has worked
fine for me, so far. I actually start my apps from a shortcut which
calls the batch file. This is so the shortcut can be given a custom
icon. My installer program sets this all up, automagically.

Cheers,
TC