[Dixie]

I have an application that does a lot of mailmerges from Access 2003 direct
to Word 2003. I have used the SQLFix registry patch up to now to address
the problem of the mailmerge not happening because it is waiting for an
authorisation to run the SQL. My main client has now gone to a standard
operating environment in which registry changes are not allowed.

My program transfers a text file with the data for merging in it and that is
set up as the data source in each word template.

Does anyone know any other way of getting around this problem?

dixie

[Cindy M.]

Hi Dixie,

I have an application that does a lot of mailmerges from Access 2003 direct
to Word 2003. I have used the SQLFix registry patch up to now to address
the problem of the mailmerge not happening because it is waiting for an
authorisation to run the SQL. My main client has now gone to a standard
operating environment in which registry changes are not allowed.

My program transfers a text file with the data for merging in it and that is
set up as the data source in each word template.

Does anyone know any other way of getting around this problem?

What, more exactly, is the problem? I understand the limitations of the
environment you're describing, but it's unclear exactly what problem you're
trying to work around.

FWIW, the client's IT department should be able to change the Registry (using a
Policy). If they don't want to, then they have to live with the prompt. Or they
have to allow you to use automation code to link in the data source "behind the
scenes" each time a mail merge is going to run. Or they have to be willing to
pay for you to develop a new solution.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 17 2005)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question or reply
in the newsgroup and not by e-mail :-)

[Dixie]

My problem is that up until now, I have been able to write the key needed to
turn the message off that makes you authorise the SQL source of a mailmerge
document. This key is:

[HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\W ord\Options]
"SQLSecurityCheck"=dword:00000000

My automation code runs out of a Microsoft Access mde file and without that
key written in the HKEY_CURRENT_USER registry for any user, the mailmerge
won't run as you can't see the authorisation message box.

My client is a large government department and they are not going to take
off their no changes to the registry policy for me. Is there a way around
writting the key where I can still get my mailmerge to work properly.

dixie

"Cindy M." wrote in message
news:VA.000000ec.01567261@speedy...
Hi Dixie,

I have an application that does a lot of mailmerges from Access 2003
direct
to Word 2003. I have used the SQLFix registry patch up to now to address
the problem of the mailmerge not happening because it is waiting for an
authorisation to run the SQL. My main client has now gone to a standard
operating environment in which registry changes are not allowed.

My program transfers a text file with the data for merging in it and that
is
set up as the data source in each word template.

Does anyone know any other way of getting around this problem?

What, more exactly, is the problem? I understand the limitations of the
environment you're describing, but it's unclear exactly what problem
you're
trying to work around.

FWIW, the client's IT department should be able to change the Registry
(using a
Policy). If they don't want to, then they have to live with the prompt. Or
they
have to allow you to use automation code to link in the data source
"behind the
scenes" each time a mail merge is going to run. Or they have to be willing
to
pay for you to develop a new solution.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 17 2005)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question or
reply
in the newsgroup and not by e-mail :-)

[Peter Jamieson]

My client is a large government department and they are not going to take
off their no changes to the registry policy for me.

If I may butt in, it isn't for "you", it's for your "sponsor", i.e. whoever
is commissioning your work.

There is no way to avoid making this registry patch. I can understand why a
support organisation would prefer not to make such a change at all, but
either your software makes the change or they apply the change to their user
systems, either globally or individually, or your sponsor has to get the
work done another way. I expect that the systems administrators make other
"changes" to the registry to make one thing or another on their systems
work, and if I were them. If they are keeping as tight a rein over what
software goes on their systems as their policy suggests, then there is
really very little reason why they should not add and set this registry key.

I do not work for Microsoft and was not involved in the design decisions
that produced this particular "security prompt" and workaround, so can only
guess why it was done. But it seems reasonable to assume that the prompt
only exists because executing SQL can have side effects (e.g. executing SQL
in Access can run a "user-defined function" which could do anything) and
prompting the user is supposed to provide "security" because it allows them
to prevent that happening. In practice, of course, only users who have built
their own software have the faintest clue whether or not a particular piece
of SQL might have damaging side effects: everyone else is just going to try
to get on with their work and reply "Yes". That is worse than no "security"
prompt at all because it does not solve the security problem, and helps
encourage a knee-jerk response in which all such dialog boxes are dismissed
as quickly as possible. Arguably, the increased complication of the system
is in itself a security risk (more code, more to go wrong). It is doubtless
there to allow legal people to claim that it is the user's "fault" if
something goes wrong.

The correct security option is that the system administrators ensure that
SQL queries with damaging side effects are not put on the system or are not
executable.

I'd try to find out who you have to go through to have the system
administrators make their change (and they have to be answerable to someone
other than themselves, otherwise someone in your government is not doing
their job). If necessary, have a word with your sponsor, explain the
background and what needs to happen. It might be valuable to have a
guesstimate to hand of how expensive it will be to do this some other way.

Peter Jamieson

"Dixie" wrote in message
...
My problem is that up until now, I have been able to write the key needed
to turn the message off that makes you authorise the SQL source of a
mailmerge document. This key is:

[HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\W ord\Options]
"SQLSecurityCheck"=dword:00000000

My automation code runs out of a Microsoft Access mde file and without
that key written in the HKEY_CURRENT_USER registry for any user, the
mailmerge won't run as you can't see the authorisation message box.

My client is a large government department and they are not going to take
off their no changes to the registry policy for me. Is there a way around
writting the key where I can still get my mailmerge to work properly.

dixie

"Cindy M." wrote in message
news:VA.000000ec.01567261@speedy...
Hi Dixie,

I have an application that does a lot of mailmerges from Access 2003
direct
to Word 2003. I have used the SQLFix registry patch up to now to
address
the problem of the mailmerge not happening because it is waiting for an
authorisation to run the SQL. My main client has now gone to a standard
operating environment in which registry changes are not allowed.

My program transfers a text file with the data for merging in it and
that is
set up as the data source in each word template.

Does anyone know any other way of getting around this problem?

What, more exactly, is the problem? I understand the limitations of the
environment you're describing, but it's unclear exactly what problem
you're
trying to work around.

FWIW, the client's IT department should be able to change the Registry
(using a
Policy). If they don't want to, then they have to live with the prompt.
Or they
have to allow you to use automation code to link in the data source
"behind the
scenes" each time a mail merge is going to run. Or they have to be
willing to
pay for you to develop a new solution.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 17 2005)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question or
reply
in the newsgroup and not by e-mail :-)

[Dixie]

I have been playing around with calling the mailmerge templates by using
Shell. The advantage seems to be that you are actually shelled out of
Access when Word loads and I think it will work in as much as the user could
see the SQL authorisation prompt. What I am not sure of however is what
other side effects this will have on the functionality. I develop using
Access 2000 and Word 2000, so can't actually test what I do in Office 2003
until I go on site and try it.

Any comments on the pros and cons of shelling to Word?

I have spoken to one of the people in charge of putting the "tied down"
operating system in place and told him what it would do to this program.
His reply was that his time was taken up making sure each site had the new
network system in place and not in "sorting out problems for third party
software developer."

Would you believe it!!!

Another question too. If I change the security of Access to 'low' via Tools
Macros Security. How does the new security setting get stored? I would
think it changes the registry key, which in theory could not be done on such
a system?

dixie

"Peter Jamieson" wrote in message
...
My client is a large government department and they are not going to take
off their no changes to the registry policy for me.

If I may butt in, it isn't for "you", it's for your "sponsor", i.e.
whoever is commissioning your work.

There is no way to avoid making this registry patch. I can understand why
a support organisation would prefer not to make such a change at all, but
either your software makes the change or they apply the change to their
user systems, either globally or individually, or your sponsor has to get
the work done another way. I expect that the systems administrators make
other "changes" to the registry to make one thing or another on their
systems work, and if I were them. If they are keeping as tight a rein over
what software goes on their systems as their policy suggests, then there
is really very little reason why they should not add and set this registry
key.

I do not work for Microsoft and was not involved in the design decisions
that produced this particular "security prompt" and workaround, so can
only guess why it was done. But it seems reasonable to assume that the
prompt only exists because executing SQL can have side effects (e.g.
executing SQL in Access can run a "user-defined function" which could do
anything) and prompting the user is supposed to provide "security" because
it allows them to prevent that happening. In practice, of course, only
users who have built their own software have the faintest clue whether or
not a particular piece of SQL might have damaging side effects: everyone
else is just going to try to get on with their work and reply "Yes". That
is worse than no "security" prompt at all because it does not solve the
security problem, and helps encourage a knee-jerk response in which all
such dialog boxes are dismissed as quickly as possible. Arguably, the
increased complication of the system is in itself a security risk (more
code, more to go wrong). It is doubtless there to allow legal people to
claim that it is the user's "fault" if something goes wrong.

The correct security option is that the system administrators ensure that
SQL queries with damaging side effects are not put on the system or are
not executable.

I'd try to find out who you have to go through to have the system
administrators make their change (and they have to be answerable to
someone other than themselves, otherwise someone in your government is not
doing their job). If necessary, have a word with your sponsor, explain the
background and what needs to happen. It might be valuable to have a
guesstimate to hand of how expensive it will be to do this some other way.

Peter Jamieson

"Dixie" wrote in message
...
My problem is that up until now, I have been able to write the key needed
to turn the message off that makes you authorise the SQL source of a
mailmerge document. This key is:

[HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\W ord\Options]
"SQLSecurityCheck"=dword:00000000

My automation code runs out of a Microsoft Access mde file and without
that key written in the HKEY_CURRENT_USER registry for any user, the
mailmerge won't run as you can't see the authorisation message box.

My client is a large government department and they are not going to take
off their no changes to the registry policy for me. Is there a way
around writting the key where I can still get my mailmerge to work
properly.

dixie

"Cindy M." wrote in message
news:VA.000000ec.01567261@speedy...
Hi Dixie,

I have an application that does a lot of mailmerges from Access 2003
direct
to Word 2003. I have used the SQLFix registry patch up to now to
address
the problem of the mailmerge not happening because it is waiting for an
authorisation to run the SQL. My main client has now gone to a
standard
operating environment in which registry changes are not allowed.

My program transfers a text file with the data for merging in it and
that is
set up as the data source in each word template.

Does anyone know any other way of getting around this problem?

What, more exactly, is the problem? I understand the limitations of the
environment you're describing, but it's unclear exactly what problem
you're
trying to work around.

FWIW, the client's IT department should be able to change the Registry
(using a
Policy). If they don't want to, then they have to live with the prompt.
Or they
have to allow you to use automation code to link in the data source
"behind the
scenes" each time a mail merge is going to run. Or they have to be
willing to
pay for you to develop a new solution.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 17 2005)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question
or reply
in the newsgroup and not by e-mail :-)

[Peter Jamieson]

Hi Dixie,

Any comments on the pros and cons of shelling to Word?

Not really - it's not something I do here. I'm sure "try it and see" is the
right approach though.

I have spoken to one of the people in charge of putting the "tied down"
operating system in place and told him what it would do to this program.
His reply was that his time was taken up making sure each site had the new
network system in place and not in "sorting out problems for third party
software developer."

Would you believe it!!!

Unfortunately, I would :-) All I can say is that it is usually necessary to
identify who has the authority to make change happen, and make your case to
them as directly as possible. Sometimes such people are rather more
accommodating than their reputation suggests.

Another question too. If I change the security of Access to 'low' via
Tools
Macros Security. How does the new security setting get stored? I
would
think it changes the registry key, which in theory could not be done on
such a system?

I don't know, but I would have to assume that even if it isn't actually a
registry change, it's another thing that you will probably not be allowed to
change on a user system.

Best I can do!

Peter Jamieson

"Dixie" wrote in message
...
I have been playing around with calling the mailmerge templates by using
Shell. The advantage seems to be that you are actually shelled out of
Access when Word loads and I think it will work in as much as the user
could see the SQL authorisation prompt. What I am not sure of however is
what other side effects this will have on the functionality. I develop
using Access 2000 and Word 2000, so can't actually test what I do in Office
2003 until I go on site and try it.

Any comments on the pros and cons of shelling to Word?

I have spoken to one of the people in charge of putting the "tied down"
operating system in place and told him what it would do to this program.
His reply was that his time was taken up making sure each site had the new
network system in place and not in "sorting out problems for third party
software developer."

Would you believe it!!!

Another question too. If I change the security of Access to 'low' via
Tools
Macros Security. How does the new security setting get stored? I
would
think it changes the registry key, which in theory could not be done on
such a system?

dixie

"Peter Jamieson" wrote in message
...
My client is a large government department and they are not going to
take off their no changes to the registry policy for me.

If I may butt in, it isn't for "you", it's for your "sponsor", i.e.
whoever is commissioning your work.

There is no way to avoid making this registry patch. I can understand why
a support organisation would prefer not to make such a change at all, but
either your software makes the change or they apply the change to their
user systems, either globally or individually, or your sponsor has to get
the work done another way. I expect that the systems administrators make
other "changes" to the registry to make one thing or another on their
systems work, and if I were them. If they are keeping as tight a rein
over what software goes on their systems as their policy suggests, then
there is really very little reason why they should not add and set this
registry key.

I do not work for Microsoft and was not involved in the design decisions
that produced this particular "security prompt" and workaround, so can
only guess why it was done. But it seems reasonable to assume that the
prompt only exists because executing SQL can have side effects (e.g.
executing SQL in Access can run a "user-defined function" which could do
anything) and prompting the user is supposed to provide "security"
because it allows them to prevent that happening. In practice, of course,
only users who have built their own software have the faintest clue
whether or not a particular piece of SQL might have damaging side
effects: everyone else is just going to try to get on with their work and
reply "Yes". That is worse than no "security" prompt at all because it
does not solve the security problem, and helps encourage a knee-jerk
response in which all such dialog boxes are dismissed as quickly as
possible. Arguably, the increased complication of the system is in itself
a security risk (more code, more to go wrong). It is doubtless there to
allow legal people to claim that it is the user's "fault" if something
goes wrong.

The correct security option is that the system administrators ensure that
SQL queries with damaging side effects are not put on the system or are
not executable.

I'd try to find out who you have to go through to have the system
administrators make their change (and they have to be answerable to
someone other than themselves, otherwise someone in your government is
not doing their job). If necessary, have a word with your sponsor,
explain the background and what needs to happen. It might be valuable to
have a guesstimate to hand of how expensive it will be to do this some
other way.

Peter Jamieson

"Dixie" wrote in message
...
My problem is that up until now, I have been able to write the key
needed to turn the message off that makes you authorise the SQL source
of a mailmerge document. This key is:

[HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\W ord\Options]
"SQLSecurityCheck"=dword:00000000

My automation code runs out of a Microsoft Access mde file and without
that key written in the HKEY_CURRENT_USER registry for any user, the
mailmerge won't run as you can't see the authorisation message box.

My client is a large government department and they are not going to
take off their no changes to the registry policy for me. Is there a way
around writting the key where I can still get my mailmerge to work
properly.

dixie

"Cindy M." wrote in message
news:VA.000000ec.01567261@speedy...
Hi Dixie,

I have an application that does a lot of mailmerges from Access 2003
direct
to Word 2003. I have used the SQLFix registry patch up to now to
address
the problem of the mailmerge not happening because it is waiting for
an
authorisation to run the SQL. My main client has now gone to a
standard
operating environment in which registry changes are not allowed.

My program transfers a text file with the data for merging in it and
that is
set up as the data source in each word template.

Does anyone know any other way of getting around this problem?

What, more exactly, is the problem? I understand the limitations of the
environment you're describing, but it's unclear exactly what problem
you're
trying to work around.

FWIW, the client's IT department should be able to change the Registry
(using a
Policy). If they don't want to, then they have to live with the prompt.
Or they
have to allow you to use automation code to link in the data source
"behind the
scenes" each time a mail merge is going to run. Or they have to be
willing to
pay for you to develop a new solution.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 17 2005)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question
or reply
in the newsgroup and not by e-mail :-)