Rationale for frustrating datasource prompt

M

Mark Tangard

In Word 2003, when you open a mailmerge main document that’s attached to a
datasource that’s been moved or deleted, you get a confusing dialog asking to
confirm the old datasource. (I’m not at a regular PC or I’d quote it; but anyone
into mailmerge is probably familiar with it.)

I know how to stop it, but I’m at a loss to explain to trainees why it happens.

Just what IS the rationale for that dialog? I can’t fathom it being necessary or
useful to ordinary users. My users often need to edit & reuse old mailmerge docs
whose datasources are long gone. Is that such an arcane need? Why does Word not
let them edit the merge doc, just because it has no datasource attached yet?

The meaning of that dialog is over most users’ heads and I’d never seen it
before 2003. Does anyone know the reason it was added?

Thanks folks.
MT
 
P

Peter Jamieson

You mean the one that says "abc.doc is a mail merge main document. Word
cannot find its data source, xyz.doc" or whatever, and has two buttons,
"Find data source" and "Options" ?

If so,
a.
I’d never seen it before 2003. Does anyone know the reason it was added?

FWIW, a similar dialog has been there since Word for Windows 2 (where it
says "abc.doc is a Print Merge Main Document which has the data file xyz.doc
referenced in a {data} statement. Word was unable to open xyz.doc" and has 4
buttons, Switch/Locate Data File..., Remove Data Statement, Leave Data
Statement and Help). In WfW1 you saw no message until you actually tried to
merge. I'd suggest that a feature added in WfW2 probably wasn't added for
the kind of security reasons that would probably be used now (e.g. you don't
want malicious code to be able to jump in and modify a data source when the
document is opening).

I only mention that because the "started with 2003" thing suggests you might
be talking about another dialog. However, it's also possible that you
started to notice this dialog more in more recent versions of Word because,
for example, if you create a merge applicaiton with a mail merge main
document and .doc data source in the same folder, then move the application
to a different folder, Word will (probably) find the data source without
prompting, even though an unambiguous path name is embedded in the .doc
file. Word will also look under "My DOcuments", and probably other places as
well. However, if your data source is a .mdb, Word will probably /not/ find
a relocated .mdb automatically. So if you always used .docs, the problem may
not appear so often.

As usual, you really have to ask the Word developers what their rationale
was for adding this. I suppose the most obvious possibility is that if you
provide a mailmerge "application" to an end user then when they open the
mailmerge main document and the data source has gone, Word can either
a. do nothing or
b. display an error, then drop the user in the document or
c. do something along the lines of what it does now or
d. perhaps something else I haven't even considered

The trouble with (a) and (b) is that the user is supposed to be using this
application: how do they know what to do next? You could argue that in that
case the mailmerge application is broken (cf. an application with a missing
dll) and that either the user should know how to fix it (by finding the
right menu and connecting a new data source) or should basically report the
problem to their IT people as with any other faulty application. But I guess
MS chose to provide a more interventionist interface.

It seems to me that there are several problems with the existing modus
operandi and dialog, some of which are probably conseqeunces of the overall
design of mailmerge in Word:
a. Word sometimes searches, and sometimes does not, as I have suggested.
This may be confusing in itself. In particular, if you copy a mail merge
main document and a .doc data source to another folder, Word will still open
the original data source.
b. Word goes through this process and displays the dialog before any VBA
executes, so a programmer cannot detect a "missing data source" situation
and do something about it.
c. If the data source cannot be found, there is no option that leaves the
/information/ about the data source in the document. So anyone who wants to
know the datasource name, connection string and query can only easily do so
if the data source still exists. People who are upgrading/reorganising
systems are stuck - they can't open the document to discover the details,
and VBA can't find out for them/
d. There probably isn't a great deal of difference in practice between the
"remove header source and data source" and "remove all merge info" options
unless you have a label or envelope merge where Word is, I suppose, more
likely to lead you to the envelope/label dialog if you change the merge type
back to "not a merge" then try to set it up as a label or envelope merge.
However, in either case, you lose a lot more than the name of the data
source - you lose the connection string and query, which means you lose any
sort and filter options. You probably also lose individual selections made
in the Mailmerge Recipients dialog. To me, maybe it would have been better
to be able to retain the /information/ and merely toggle the merge
functionailty on and off.
e. if you don't know how merge works, the dialogs seem to me to be fairly
obtuse. Even if you do, it's not completely clear what the options will do.
And these are not the only dialogs you may face when opening a mail merge
main document - you may also get the SQL dialog issued by Word, and you are
also much more likely to get
dialogs from other applications now. So the user potentially has to wade
through a barrage of dialogs.

There's probably other stuff, but that's perhaps enough for now.

Personally I think it would be rather better if Word allowed the start-up
behaviour to be determined document-by-document, allowed the merge
information to be inspected by code prior to any dialogs, and allowed
retention of merge information even when the document is not actively
configured to be a merge document (although some people might of course say
that retention of invisible information like that is potentially a security
risk).
 
P

Peter Jamieson

It's not either of the dialogs you mention -- and of course, now I can't
reproduce it no matter how much I taunt Word; go figure.

Well, maybe one of your users will run into it again soon. I probably run
into it as well but my memory's shot these days and I don't write enough
down...

Peter Jamieson
 
M

Mark Tangard

Hi Peter,

Intesting insights, and I totally agree on your final paragraph.

It's not either of the dialogs you mention -- and of course, now I can't
reproduce it no matter how much I taunt Word; go figure. (All these years I've
just snarled at it.) Was just looking for some fuel for explaining it to one of
my users. Thanks for that.

Mark
 
M

Mark Tangard

Hi Peter,

Intesting insights, and I totally agree on your final paragraph.

It's not either of the dialogs you mention -- and of course, now I can't
reproduce it no matter how much I taunt Word; go figure. (All these years I've
just snarled at it.) Was just looking for some fuel for explaining it to one of
my users. Thanks for that.

Mark
 
P

Peter Jamieson

It's not the message titled "Security warning" that says

Opening "the pathname of a .mdb file"

"This file may not be safe if it contains code intended to harm your
computer..." etc. ?

If so, I think you only get /that/ one when you open a .mdb using DDE and
the warning is actually issued by Access and can be fixed in the usual ways
(modify macro security levels in Access, sign code etc.)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top