By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,649 Members | 1,816 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,649 IT Pros & Developers. It's quick & easy.

"FE Updater" and macro security

P: n/a
Hi

I've seen details on bypassing macro security with a bat file but has any one
incorporated this with Tony Toews FE Updater?

If so, I'd appreciate some guidance. As both open the database I'm not sure
how/if this will work.

Thanks

--
Darren

Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200704/1

Apr 4 '07 #1
Share this Question
Share on Google+
28 Replies


P: n/a
darren via AccessMonster.com wrote:
I've seen details on bypassing macro security with a bat file but has any one
incorporated this with Tony Toews FE Updater?

If so, I'd appreciate some guidance. As both open the database I'm not sure
how/if this will work.
If we're talking A2003, I have macro security set to low and all is fine.
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Be Careful, Big Bird!" - Ditto "TIM-MAY!!" - Me
Apr 4 '07 #2

P: n/a
Hi Tim, thanks for taking the time.

To set the macro security on each users PC/Access would defy their IT policy.
I believe that by opening the database with a bat file you can set the
security to low for just that instance/session. The script I have seen to do
this opens access. However, I use the FE updater and that already handles the
opening of access.

Tony's site mentions the ability of using a bat file but I believe the script
required may clash with the updaters own intended use.

--
Darren

Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200704/1

Apr 5 '07 #3

P: n/a
"darren via AccessMonster.com" <u11419@uweschreef in bericht news:703d095265a97@uwe...
Hi Tim, thanks for taking the time.

To set the macro security on each users PC/Access would defy their IT policy.
I believe that by opening the database with a bat file you can set the
security to low for just that instance/session. The script I have seen to do
this opens access. However, I use the FE updater and that already handles the
opening of access.

Tony's site mentions the ability of using a bat file but I believe the script
required may clash with the updaters own intended use.

--
Darren

Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200704/1

Where have you seen this bat-file you are talking about?
I might be interested.

Arno R
Apr 5 '07 #4

P: n/a
darren via AccessMonster.com wrote:
To set the macro security on each users PC/Access would defy their IT policy.
I believe that by opening the database with a bat file you can set the
security to low for just that instance/session. The script I have seen to do
this opens access. However, I use the FE updater and that already handles the
opening of access.

Tony's site mentions the ability of using a bat file but I believe the script
required may clash with the updaters own intended use.
I see, hmmmmm.

IN my organization, there's no "standard" setting for the macro
security, although most users come to me and want to know how to turn
the irritating start up message off. However, as far as I know, Tony's
utility doesn't open Access - it checks last modified dates on the
windows file. Now I could be wrong on this. However, I haven't had any
problems with the updater not working on the default medium (I don't
know if anyone has set it to high) security setting. That said, it
could be because no one has it at medium anymore, but given my
understanding of how Tony's excellent utility works, it shouldn't matter.

In fact, it doesn't. I just did a quick experiment to see. here's what
I did.

I changed macro security from low to medium (the MS recommended default)
and turned off all my Access apps. I then turned on the main app that
is launched by the Auto FE Updater short cut created by Tony's utility.
Since there was no new version of it on the server, it started
immediately, however, the Security warning dialog did appear. This is
the expected behaviour.

Next, I put a new copy of the front end onto the server location
specified by the Auto FE Updater shortcut, ie, the location from which
my users draw the newest FE via their own Auto FE Updater shortcuts when
I make updates to it. I then closed all my apps on my machine and
double clicked the Auto FE Updater shortcut for the app in question.

What happened was that before Access started, the new version of the FE
was copied over first, at least according to the "copying" dialog that
appears when the new FE is copied. It was only after that was finished
that the FE opened in Access and, again, I was confronted with the
security dialog.

So, my conclusion is that the Auto FE Updater shortcut will update the
front end and only pop up the security message when the Access FE is
opened. It seems to me you needn't worry about any conflicts. 8)

But the original question still remains, I guess, and that is how to
bypass the warning altogether and use the Auto FE Updater shortcut. 8)
For that you'd probably best write Tony from the web site.
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Be Careful, Big Bird!" - Ditto "TIM-MAY!!" - Me
Apr 5 '07 #5

P: n/a
"darren via AccessMonster.com" <u11419@uwewrote:
>To set the macro security on each users PC/Access would defy their IT policy.
I believe that by opening the database with a bat file you can set the
security to low for just that instance/session.
Not to my knowledge. But I sure could be wrong. I don't see anything like that when
I look at the startup options help page.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Apr 5 '07 #6

P: n/a
"darren via AccessMonster.com" <u11419@uwewrote:
>I've seen details on bypassing macro security with a bat file
Do you have those handy? I might add that to the Auto FE Updater.

Tony

--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Apr 5 '07 #7

P: n/a
Note that Tony Toews is a MDB _WUSS_ and should not be trusted for
anything.

It's like going to ask a 1st grader for financial advice
ADP uber alles!


On Apr 5, 10:20 am, "Tony Toews [MVP]" <tto...@telusplanet.netwrote:
"darren via AccessMonster.com" <u11419@uwewrote:
I've seen details on bypassing macro security with a bat file

Do you have those handy? I might add that to the Auto FE Updater.

Tony

--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems athttp://www.granite.ab.ca/accsmstr.htm

Apr 5 '07 #8

P: n/a
Tony Toews [MVP] wrote:
"darren via AccessMonster.com" <u11419@uwewrote:

>>I've seen details on bypassing macro security with a bat file


Do you have those handy? I might add that to the Auto FE Updater.
I haven't seen a .bat/.cmd technique but this sample from "TC" shows a VBScript technique:
-----------------------

And a very interesting work-around presented by TC.
This particular technique, however, will not work with a secured database:

"IMO the best 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 used it successfully in the past for little things - e.g. update programs. I'm assume
you'd provide the user the ability to decide whether to use this technique or not.
--
---------------
John Mishefske, Microsoft Access MVP
Apr 6 '07 #9

P: n/a
John Mishefske <jm**********@SPAMyahoo.comwrote:
>Do you have those handy? I might add that to the Auto FE Updater.

I haven't seen a .bat/.cmd technique but this sample from "TC" shows a VBScript technique:
Ahh, yes, thanks for that. I have seen that technique before and had completely
forgotten about it.

Hmm, I have a client where that could prove useful. I wonder how you can create and
call a VBScript in VB6.

Tony
>I'm assume
you'd provide the user the ability to decide whether to use this technique or not.
Absolutely. This would be aetting in the INI file.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Apr 6 '07 #10

P: n/a
John Mishefske <jm**********@SPAMyahoo.comwrote:
>dim o
set o=createobject ("Access.Application")
o.automationsecurity=1 ' set macro security LOW.
o.opencurrentdatabase "full path to your database"
o.usercontrol=true
Ah, no, I should be able to run that directly from within VB. Duhhh!!!

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Apr 6 '07 #11

P: n/a
Tony Toews [MVP] wrote:
John Mishefske <jm**********@SPAMyahoo.comwrote:

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


Ah, no, I should be able to run that directly from within VB. Duhhh!!!
Yes.

--
---------------
John Mishefske, Microsoft Access MVP
Apr 6 '07 #12

P: n/a
John Mishefske <jm**********@SPAMyahoo.comwrote:
>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
There is one problem with this approach. According to the below page the only
parameters you can specify are (filepath, Exclusive, bstrPassword). Thus you can't
pass any of the startup options such as /runtime or MDW file name. However many
people don't use them anyhow so that's not a serious problem but a limitation.

OpenCurrentDatabase Method [Access 2003 VBA Language Reference]
http://msdn2.microsoft.com/en-us/lib...ffice.11).aspx

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Apr 6 '07 #13

P: n/a
Tony Toews [MVP] wrote:
John Mishefske <jm**********@SPAMyahoo.comwrote:

>>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


There is one problem with this approach. According to the below page the only
parameters you can specify are (filepath, Exclusive, bstrPassword). Thus you can't
pass any of the startup options such as /runtime or MDW file name. However many
people don't use them anyhow so that's not a serious problem but a limitation.

OpenCurrentDatabase Method [Access 2003 VBA Language Reference]
http://msdn2.microsoft.com/en-us/lib...ffice.11).aspx

Tony
Agreed - not a big limitation.

I always assumed that /runtime option was just there for testing. Is there any reason
someone would use it in production version (instead of a .MDE)?

It is unfortunate that a workgroup can't be used here.

--
---------------
John Mishefske, Microsoft Access MVP
Apr 7 '07 #14

P: n/a
"darren via AccessMonster.com" <u11419@uwewrote:
>I've seen details on bypassing macro security with a bat file but has any one
incorporated this with Tony Toews FE Updater?
The Auto Fe Updater has now been updated to add this functionality.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Apr 7 '07 #15

P: n/a
On Apr 7, 12:25 pm, "Tony Toews [MVP]" <tto...@telusplanet.netwrote:
"darren via AccessMonster.com" <u11419@uwewrote:
I've seen details on bypassing macro security with a bat file but has any one
incorporated this with Tony Toews FE Updater?

The Auto Fe Updater has now been updated to add this functionality.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems athttp://www.granite.ab.ca/accsmstr.htm
I have Access 2003 and Access 2007 installed on my machine. I
haven't used Access 2007 for weeks, but when I tried the new Auto FE
Updater, it started Access 2007 (with the painful accompanying install
process that takes place the first time that it is started after using
another version). I was using the same .ini file that I was using
with the last version of the Updater.

Has something been changed in the .exe file to make it default to the
newest installed version of Access?

Apr 8 '07 #16

P: n/a
"Wayne" <cq*******@volcanomail.comwrote:
>I have Access 2003 and Access 2007 installed on my machine. I
haven't used Access 2007 for weeks, but when I tried the new Auto FE
Updater, it started Access 2007 (with the painful accompanying install
process that takes place the first time that it is started after using
another version). I was using the same .ini file that I was using
with the last version of the Updater.

Has something been changed in the .exe file to make it default to the
newest installed version of Access?
Yes. That is how it has always worked. But now that I just added the logic to see
if A2007 exists it starts with A2007 rather than the previous version of Access.
Which is painful for someone who works in versions other than A2007.

Hmm, I gotta think about this one a bit.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Apr 8 '07 #17

P: n/a
Yes. That is how it has always worked. But now that I just added the logic to see
if A2007 exists it starts with A2007 rather than the previous version of Access.
Which is painful for someone who works in versions other than A2007.

On my machine the old .exe file would start Access 2003 (the most
recently opened version). When I used the new .exe file it opened
Access 2007. Not sure why this is if it designed to work the same as
the old version. By the way, thanks for an excellent utility.
Apr 9 '07 #18

P: n/a
Hi All

Just back from a long bank holiday weekend. Blimey, the thread has progressed.
Yep, that VBScript is what I was referring to to add into a .bat but I see
Tony has already jumped one step ahead of me and kindly added it. (As well as
sorting the ACC2007 issue I had the other day).

Regretably I do use need to use passwords in this instance, but this was a
nice to have, and certainly makes a good feature for the updater.

Thanks All and a special thanks to Tony.

--
Darren

Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200704/1

Apr 10 '07 #19

P: n/a
"Wayne" <cq*******@volcanomail.comwrote:
>On my machine the old .exe file would start Access 2003 (the most
recently opened version). When I used the new .exe file it opened
Access 2007. Not sure why this is if it designed to work the same as
the old version.
Actually the way the utility currently works is it looks at the version of the
MDB/MDE. Then it goes down the registry keys from newest version to oldest looking
for a version of Access that is allegedly installed on your system. Then it executes
that version. So if you had A2000 and A2003 installed with an A2000 MDB/MDE it
would run A2003. I did this mostly because the assumption on my part was that A2003
would be inherently more stable.

However given the huge switching times with A2007 this is a royal PITA for the
developers. Now end users aren't likely going to have this problem because they will
very likely only have one version of Access installed.

So I'm thinking of what is the best way to handle this. Do I reverse the order to
look through the registry keys? Or do I add another entry line that has a default
version of Access? The latter approach would be better for ADPs as the utility
doesn't handle those gracefully at all.
>By the way, thanks for an excellent utility.
Thanks for your kind words.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Apr 10 '07 #20

P: n/a
"darren sawyer via AccessMonster.com" <u11419@uwewrote:
>Regretably I do use need to use passwords in this instance, but this was a
nice to have, and certainly makes a good feature for the updater.
I wish I had a choice but I don't.
>Thanks All and a special thanks to Tony.
You're quite welcome.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Apr 10 '07 #21

P: n/a
However given the huge switching times with A2007 this is a royal PITA for the
developers.
Is anyone lobbying Microsoft to provide a resolution to this issue?
At the moment it's almost unworkable (or at least very demanding on
one's patience) to have A2007 and another version on the same
machine. I think that developers will need A2003 and possibly A2000
for some time into the future.

At the moment A2003 and A2000 seem to coexist OK together when they
feel like it. At least when they don't the "reinstall" time for these
two versions is relatively painless, unlike A2007. Running two
machines with A2007 on one and the other two versions on the other
isn't an ideal situation either.

Apr 11 '07 #22

P: n/a
"Wayne" <cq*******@volcanomail.comwrote:
>However given the huge switching times with A2007 this is a royal PITA for the
developers.

Is anyone lobbying Microsoft to provide a resolution to this issue?
At the moment it's almost unworkable (or at least very demanding on
one's patience) to have A2007 and another version on the same
machine. I think that developers will need A2003 and possibly A2000
for some time into the future.
Oh yes. MVPs have made their opinion on this topic very loud and clear.
>At the moment A2003 and A2000 seem to coexist OK together when they
feel like it. At least when they don't the "reinstall" time for these
two versions is relatively painless, unlike A2007.
Agreed. I'm currently running A2000, A2002 and A2003 with no problems moving back
and forth.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Apr 11 '07 #23

P: n/a
I call the following code when I open my Access applications:

DoCmd.RunCommand acCmdAppMaximize

Despite this, when I have the "StartMethod" switch set to
"LowMacroSecurity" my apps repeatedly open in a sized window roughly
about half the size of my 1280 x 1024 screen. If I change the
switch back to "AutoSelect", the application opens maximized. Any
ideas?
Apr 13 '07 #24

P: n/a
Is there anyone else using the lastest Auto FE Updater who is seeing
this problem? i.e. the Access window opens sized instead of maximized
if the "LowMacroSecurity" switch is used in the .ini file. Without
the "LowMacroSecurity" switch the Access window opens maximized.

Apr 15 '07 #25

P: n/a
"Wayne" <cq*******@volcanomail.comwrote:
>Is there anyone else using the lastest Auto FE Updater who is seeing
this problem? i.e. the Access window opens sized instead of maximized
if the "LowMacroSecurity" switch is used in the .ini file. Without
the "LowMacroSecurity" switch the Access window opens maximized.
Yes, I'm seeing the same thing here. Rather irritating that. And rather useless. I
should find some code that will maximize the window.

Supposedly the following would work. But weird things happen.
http://c85.cemi.rssi.ru/Access/Queri...l.asp?TipID=31

Sorry about not replying to your previous message. I hadn't read it properly so
misunderstood your point.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Apr 16 '07 #26

P: n/a
"Tony Toews [MVP]" <tt****@telusplanet.netwrote:
>>Is there anyone else using the lastest Auto FE Updater who is seeing
this problem? i.e. the Access window opens sized instead of maximized
if the "LowMacroSecurity" switch is used in the .ini file. Without
the "LowMacroSecurity" switch the Access window opens maximized.

Yes, I'm seeing the same thing here. Rather irritating that. And rather useless. I
should find some code that will maximize the window.

Supposedly the following would work. But weird things happen.
http://c85.cemi.rssi.ru/Access/Queri...l.asp?TipID=31
There is also code at API: Manipulate Access Window
http://mvps.org/access/api/api0019.htm
However again wierd things happen to Access when called using the LowMacroSecurity
option and this code. Basically an empty window appears. No menu, no toolbars and
no forms.

While the code works just fine when executed from a database which was launched
normally.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Apr 16 '07 #27

P: n/a
"Wayne" <cq*******@volcanomail.comwrote:
>Is there anyone else using the lastest Auto FE Updater who is seeing
this problem? i.e. the Access window opens sized instead of maximized
if the "LowMacroSecurity" switch is used in the .ini file. Without
the "LowMacroSecurity" switch the Access window opens maximized.
I've updated the appropriate web pages.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Apr 16 '07 #28

P: n/a
"Tony Toews [MVP]" <tt****@telusplanet.netwrote:
>>>Is there anyone else using the lastest Auto FE Updater who is seeing
this problem? i.e. the Access window opens sized instead of maximized
if the "LowMacroSecurity" switch is used in the .ini file. Without
the "LowMacroSecurity" switch the Access window opens maximized.

Yes, I'm seeing the same thing here. Rather irritating that. And rather useless. I
should find some code that will maximize the window.
There is also code at API: Manipulate Access Window
http://mvps.org/access/api/api0019.htm
However again wierd things happen to Access when called using the LowMacroSecurity
option and this code. Basically an empty window appears. No menu, no toolbars and
no forms.

While the code works just fine when executed from a database which was launched
normally.
If anyone would like to play with this problem I'll be happy to email them a zip file
with two MDBs with code that illustrate this problem.

Tony (tony at granite dot ab dot ca)
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Apr 16 '07 #29

This discussion thread is closed

Replies have been disabled for this discussion.