Re: mailmerge out of Access 2003

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 *** 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" <dixie@xxxxxxxxxxx> wrote in message
news:12ecqqq5nd68qd8@xxxxxxxxxxxxxxxxxxxxx
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\Word\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." <C.Meister-C@xxxxxxxxxx> wrote in message
news:VA.000000ec.01567261@xxxxxxxxx
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 :-)





.