You did well to connect to a data source that's an HTTP URL - FWIW, I
had never found a way to do it within the Word UI or using VBA
OpenDataSource, but specifying the URL in the XML works here too.
Unfortunately, that seems to be about as good as it gets. The following
may tell you something, but it's hard to see how you could actually
achieve your objective.
At least one of the prompts is probably the SQL-related prompt that
requires a registry fix on the user's machine:
http://support.microsoft.com/kb/825765
So that's not something you can modify on behalf of your site users
(uness they are all actually on your own corporate network, in which
case I suppose it is at least feasible).
You used to be able to avoid that prompt using RTF and removing the SQL, but
a. there was a time when Word would discard any mailmerge info. in RTF
format files
b. Microsoft seemed to close off that possibility in an update a year
or so ago.
c. I don't know whether the equivalent approach ever worked in XML.
However, I don't know what other messages you are seeing. Here, the most
significant difference in behaviour is to do with whether the URL where
the .csv is located is trusted by Internet Explorer. If it isn't, Word
won't connect. If it is, Word will connect, but my experience with Word
2007/Vista suggests that it is always actually dealing with a downloaded
copy "behind the scenes" as you suggest. And again, unless you have
control over what URLs your users' system trust, there is no simple fix
for that.
Even the new Word 2007 approach of using content controls and putting
all the data in a custom XML data store isn't workable unless you can
guarantee that your users can download and execute a complete VSTO-type
Word document with the .NET code to point to each record in turn and
produce tear-off copies of the document.
Best I can do, sorry.
Peter Jamieson
http://tips.pjmsn.me.uk
Mark McGinty wrote:
env: Word 2003+
Greets,
I'm trying to do something that, on the surface, seemed pretty basic: I need
to serve-up a Word mail-merge document (as XML) over HTTP, that is already
linked to data that is also served over HTTP.
The closest I have gotten is to link .csv data by setting the attributes
(defined using XPath) w:wordDocument/w:docPr/w:mailMerge/w:query@w:val
and w:wordDocument/w:docPr/w:mailMerge/w:dataSource@w:val to a URL.
(w:query@w:val must be prefixed with "SELECT * FROM"; oddly, both must be
set.)
This actually does work, except that it prompts annoyingly, 2 to 3 times.
The first time I could accept (the prompt references the URL) but the
"extra" prompts make the functionality look dumb (they apparently reference
some locally cached alias -- from a user standpoint, it looks really lame.)
To summarize, we want to provide a Word mail merge all pre-prepared, no user
intervention required, as a feature of a web site. We don't want to expose
any SQL Servers to the public Internet (for obvious reasons) and we
absolutely do NOT want to use Jet (not explicitly, anyway.) Our current
solution (which had to support Word 2000) involves use of Office automation
objects and the scripting file system object -- difficult to support to say
the least.
At one point it looked to me like there was a way to embed the merge data
inside the [xml] document itself, though I can't find a way to make that
happen via Word's UI. (Otoh, I couldn't get Word to persist a URL-based
data source via UI either, and that nominally works, soooo...)
Any suggestions appreciated.
-Mark McGinty