[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.)

--
Peter Jamieson
http://tips.pjmsn.me.uk

"Mark Tangard" wrote in
message ...
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


Peter Jamieson wrote:
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).