Fixing Mail Merge header files

[scw-tzg]

I have an appl that automates Word Mail Merge. It was written a long time
ago and it uses a template document that is created and saved with an
attached Header file (csv text file) but no attached data source file. It
attaches to a generated csv Data Source file at run time.

I have clients who have been running this application successfully for many
years, but as some convert from Word 2000 (or possibly Word XP) to Office
Word 2003, they run into the dreaded "Opening this will run the following SQL
command" message. We have considered the knowledgebase article & workaround
at http://support.microsoft.com/Default.aspx?kbid=825765, but clients are
reluctant to fool with the Registry. Likewise they are unhappy with the
option of manually opening and resetting the headers in the individual
documents because they often have hundreds of these documents.

So we are developing a solution using VBScript to automate the steps that
need to be done in Word. Here's where my problem is (yes finally!) If I
manually open one of these documents, I get the error message, and I found
that if I reply YES (to the next error message as well), the document opens
with the header file and "something" set as the data source. I see that in
Mail Merge helper dialog. That would be fine; I can find out what the header
file was, then start the Mail Merge setup all over again. But when I do the
Open from vbscript, the document opens without any error message, and with
all Mail Merge settings 'erased', as if I answered NO. That doesn't work for
me! I need to know what the header dile was. Does anyone have any
suggestions? Would one of the options on the Open method help here? I also
noticed that if I select the document from Windows explorer and double-click
it or specifically use the Open command, it gives me the error message; if I
use the Edit command, it opens as it does in vbscript.

Thanks for any suggestions...

 

[Graham Mayor]

This is not 'fooling with the registry' it is applying a Microsoft
recommended switch to overcome an issue that before the update wasn't
included as a security option, so the clients will be no less secure than
they were before the security patch was applied to what at worst was only a
minuscule risk. *All* software makes changes to the registry - at least this
way you know what changes are being made!

--
<>>< ><<> ><<> <>>< ><<> <>>< <>><<>
Graham Mayor - Word MVP


<>>< ><<> ><<> <>>< ><<> <>>< <>><<>

 

[scw-tzg]

Thanks, but when Microsoft includes these 2 warnings (see below) (I always
see the *second* one when the solution involves a change to the registry, but
not the first,) it makes SysAdmins cringe. Note that it says "We do not
recommend..."; I hardly consider that Microsoft-recommended!

Incidentally, do you know how to get past my problem?

From kb#825765...
*WORKAROUND*
*Warning* This workaround may make your computer or your network more
vulnerable to attack by malicious users or by malicious software such as
viruses. We do not recommend this workaround but are providing this
information so that you can implement this workaround at your own discretion.
Use this workaround at your own risk.

*Warning* Serious problems might occur if you modify the registry
incorrectly by using Registry Editor or by using another method. These
problems might require that you reinstall your operating system. Microsoft
cannot guarantee that these problems can be solved. Modify the registry at
your own risk.

 

[Peter Jamieson]

There's another conversation in this group going on about this subject,
titled "KB 825765 - just making sure..." that you might find useful, but I
don't think it will lead to a solution for you as your requirement is
different.

Much as I dislike these warnings and the registry fix necessary to get rid
of them, I suspect that working around the messages is even harder than
making the registry fix and that, unless you can copy everything you need to
examine and perhaps modify all the .doc files affected onto a
development/test machine so you don't have to take the supposed risk of
fixing the registry on a production machine, you won't be able to extract
the info. about the existing header files without going opening each .doc
manually.

In my view, Microsoft's standard warning about registry changes is intended
to put off people who are thinking or tinkering with the registry with no
real understanding of what they are doing. While I understand the reluctance
of administrators to make these changes at all, particularly in the face of
these dire warnings,
inserting a single value like this one, perhaps using a .reg file, in
conditions controlled by the administrators, after experiments that
demonstrate that the change is not life-threatening, seems to me to be quite
a reasonable thing to do.

As for the other warning about malicious software and so on, the probable
reason why MS is providing that warning in this case is because when Word
opens a header source or data source, it may be using software that is not
part of Word, or Office, or even provided by MS. It may for example end up
using a Word text converter dll or third aprty OLE DB provider to open the
header/data source. Or Word might be opening an Access data source and
executing a user-defined query written in Access VBA. It's not hard to write
a text converter and it's just a piece of software that can do anything it
wants. However, if the administrators are confident that they can keep such
stuff off their systems, they have to weigh the two risks. By /not/ making
the registry change they are in effect saying that they are not confident
that they can keep those specific types of software off their systems. But
in that case, what can they prevent?

Peter Jamieson