Re: Fixing Mail Merge header files

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance



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

"scw-tzg" <susan 1DOT wolitz AT trizetto 1DOT com> wrote in message
news:D81C9A24-9AF4-419C-B3AA-034F04F830BA@xxxxxxxxxxxxxxxx
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.



"Graham Mayor" wrote:

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

My web site www.gmayor.com
Word MVP web site http://word.mvps.org
<>>< ><<> ><<> <>>< ><<> <>>< <>><<>

scw-tzg wrote:
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...





.



Relevant Pages

  • Re: Fixing Mail Merge header files
    ... This is not 'fooling with the registry' it is applying a Microsoft ... with an attached Header file but no attached data ... and I found that if I reply YES (to the next error message ... the document opens with the header file and "something" ...
    (microsoft.public.word.mailmerge.fields)
  • Re: Fixing Mail Merge header files
    ... *Warning* Serious problems might occur if you modify the registry ... with an attached Header file but no attached data ... and I found that if I reply YES (to the next error message ... the document opens with the header file and "something" ...
    (microsoft.public.word.mailmerge.fields)
  • Re: automating the SQL warning and the choice of text format
    ... automatically select 'yes' and 'utf-8' rather than changing the registry, ... In order to get the correct encoding, I believe that you have to do the ... You need one of those for each data source. ... For a comma-delimited file using UTF-8 encoding, ...
    (microsoft.public.word.mailmerge.fields)
  • Re: OldNormal.dot Only Worked Once
    ... it is the same Steve that you helped late last week. ... The problem as previously stated in second posting is it only works once ... Let's start with the Registry first. ... I also tried 'start','run','winword /a' and that no longer opens ...
    (microsoft.public.office.misc)
  • Re: XP Tweak not working--- Bootup Problem
    ... this will resolve the issue. ... registry damage it will not. ... >I was recently directed to the "System32 Folder Opens Upon ...
    (microsoft.public.windowsxp.general)