I've got a VB 6 application that runs mailmerge in word 2000.

I've been trying to upgrade the application to work with word 2002 with
no success. The client wants this yesterday. I've been all over the MS
website and have not come up with a solutin.

The request for the merge is:

With oDobj.ActiveWindow.Document
.MailMerge.OpenDataSource Name:=stConn, SQLStatement:=strSQL,
SubType:=wdMergeSubTypeWord2000
.MailMerge.Execute
.Close False
End With

What I've been playing with is the content of the stConn variable.
According to MS (289830) using a PATH string for the name and the
subtype reference above it should work just fine. It doesn't. I get the
template document open. When the OpenDataSource action fires nothing
happnes.

Any thoughts/comments? TIA

The following article may be relevant:

http://support.microsoft.com/default...b;en-us;825765

What type of data source are you trying to use? (Access, Excel, Word
document, etc.) For certain types of data source you will definitely need a
Connection parameter in the call.

Peter Jamieson

wrote in message
oups.com...
I've got a VB 6 application that runs mailmerge in word 2000.

I've been trying to upgrade the application to work with word 2002 with
no success. The client wants this yesterday. I've been all over the MS
website and have not come up with a solutin.

The request for the merge is:

With oDobj.ActiveWindow.Document
.MailMerge.OpenDataSource Name:=stConn, SQLStatement:=strSQL,
SubType:=wdMergeSubTypeWord2000
.MailMerge.Execute
.Close False
End With

What I've been playing with is the content of the stConn variable.
According to MS (289830) using a PATH string for the name and the
subtype reference above it should work just fine. It doesn't. I get the
template document open. When the OpenDataSource action fires nothing
happnes.

Any thoughts/comments? TIA

I have a compile that runs on my machine with Office 2002 (XP). I have
not been able to get the application to run on any other machine with
Office 2002 (XP).
I read the indicated article, but this refers to a prompt that I'm not
getting.
The application uses an Access dataase. The application opens a
template document in Word and then feeds a query to mail merge.
The application runs fine with Word 2000. It runs on my machine, and no
where else, with Word 2002 (XP). On other machines with Word 2002, the
template opens and then nothing happens. It just sits there.
Essentially, the mail merge appears to fail to fire.

Just a few thoughts:
a. the article refers to a prompt, but that's because it is not discussing
the case where the relevant operations are being done programmatically
rather than manually. As far as I can remember the OpenDataSOurce fails
without telling you. However, it may be that with proper error handling you
should be seeing this error reported.
b. when you say "template", do you mean that your Mail Merge Main Document
is a .dot file? If so, have you tried a .doc instead?
c. if you haven't tried it already, I would consider testing similar code
in a slightly simpler situation, e.g. create a test document containg a few
test fields and a macro that issues the same OpenDataSource call, and try
that on one of the non-dev. machines.

Peter Jamieson

wrote in message
oups.com...
I have a compile that runs on my machine with Office 2002 (XP). I have
not been able to get the application to run on any other machine with
Office 2002 (XP).
I read the indicated article, but this refers to a prompt that I'm not
getting.
The application uses an Access dataase. The application opens a
template document in Word and then feeds a query to mail merge.
The application runs fine with Word 2000. It runs on my machine, and no
where else, with Word 2002 (XP). On other machines with Word 2002, the
template opens and then nothing happens. It just sits there.
Essentially, the mail merge appears to fail to fire.

Sorry. I forgot to mention that I did a regedit on my machine to look
for the indicated entry. I have Office XP with the indicated SP3, but
there's no SQLSecurityCheck option in the registry. In a sense the
whole business seems a little whacked. Why would MS provide the
facilities and then suddenly decide this is a security issue and
essentially disable the capability without notifying developers? (That
may be a rhetorical question expressing my continuing frustation with
MS.)

Sorry for the delayed response.

The only suggestion I can make is that I think with the OpenDataSource code
you are using, Word will try to open the database using DDE - in other
words, it will start Access, get it to open the database, then get the data
via DDE. Is your application definitely doing that on the user workstations
(for example, if Access pops up any dialog boxes during this process - e.g.
a password dialog, or a parameter dialog box if you are connecting to or
issuing a parameter query -they may pop up behind Word and the user may not
see them. That sounds unlikely, since you would probably experience the
problem too, and your users would probably see a more visible sign of
failure eventually, but it is worth checking).

In fact, if your Access database is secured in any way (by a password, or
using workgroup security) connection will be more difficult.

In a sense the
whole business seems a little whacked. Why would MS provide the
facilities and then suddenly decide this is a security issue and
essentially disable the capability without notifying developers?

Well, I can't answer for MS as I don't work for them, but in essence "the
facilities" (i.e. to connect to external databases) have been there from an
early version of Word but they have always relied on a bit of SQL being
issued or a converter being run, and since they are not necessarily part of
Word (and may not even be MS software) there is no guarantee that they will
work as you expect. MS has tried to fix the problem by providing a warning
mechanism within Word and allowing system administrators to disable it -
i.e., in principle the warning mechanism should only be disabled if the
administrator is convinced that insecure code will not run as the
consequence of (say) an Access SQL query running some user-defined Access
VBA macro code. Tall order, IMO.

However, from what you say it does not sound as if this particular issue is
the cause of the problem.

Peter Jamieson

wrote in message
ps.com...
Sorry. I forgot to mention that I did a regedit on my machine to look
for the indicated entry. I have Office XP with the indicated SP3, but
there's no SQLSecurityCheck option in the registry. In a sense the
whole business seems a little whacked. Why would MS provide the
facilities and then suddenly decide this is a security issue and
essentially disable the capability without notifying developers? (That
may be a rhetorical question expressing my continuing frustation with
MS.)