DDE connection w/ Access & Word 2007

[mariacle]

I have a database that, back in the days when we used Office XP I had no
problems with. Now that my office has migrated to Office 2007, I'm banging
my head against the wall trying to solve what seems like a simple problem.
This problem, by the way, exists in both the old Office XP versions of the
files and my newly created Office 2007 versions.

I have a parameter query in Access that feeds a Word mail merge. When I
open the file in Word, I get the error message "Word could not re-establish a
DDE connection to Microsoft Access to complete the current task."

I can then follow the options provided to re-connect to my query and run the
query. But next time I open the file, same problem.

I've done some searching and the first suggestion I came across said it was
a security issue and I needed to set Access to trust the location the file
was saved in. Did that, still doesn't work. I then changed the settings in
Word so it trusted the file location, still no luck.

So, back to searching, next suggestion I found basically said it wasn't
going to work on a network drive. This is a problem, as both the merge docs
and the access database will be used by multiple people, but for the sake of
testing, I copy it to my local drive, add the new location to my trusted
locations in both applications, and try again. Almost the same thing
happens. This time Access is actually launched, my database is opened, but
no message box to ask for my parameter.

How do I resolve this issue once and for all, so that my users will be able
to run the merge as needed?

 

[Peter Jamieson]

So far, the only way I have found to solve this problem is to save the Mail
merge Main Document as a Word 97-2003 .doc document (in compatibility mode).
That seems to work with both .mdb and .accdb format databases. I have
exactly the same experience as you if I save the Mail Merge Main document as
a .docx (or .docm)

I've done some searching and the first suggestion I came across said it
was
a security issue and I needed to set Access to trust the location the file
was saved in. Did that, still doesn't work. I then changed the settings
in
Word so it trusted the file location, still no luck.

Trusting the folder containing the .docx and/or the .mdb (or is it a .accdb
in this case?) in Word and/or in Access may also be necessary but it is not
sufficient. I do not think it is actually necessary unless the additional
security constraints Access imposes (when you do not trust the location)
prevent Word from "seeing" the objects it needs.

So, back to searching, next suggestion I found basically said it wasn't
going to work on a network drive.

It does here.

 

[mariacle]

So far, the only way I have found to solve this problem is to save the Mail

merge Main Document as a Word 97-2003 .doc document (in compatibility mode).
That seems to work with both .mdb and .accdb format databases. I have
exactly the same experience as you if I save the Mail Merge Main document as
a .docx (or .docm)

This works IF I save the database on my local drive. If I try it with the
database on the network, the .doc doesn't even seem to be saving the link to
the data source - I open the file, no messages asking if I want to run the
query, and opening the Mailings ribbon shows the Finish & Merge button is
disabled. This happens whether my database is a .mdb of .accdb.

 

[Peter Jamieson]

This works IF I save the database on my local drive. If I try it with the

database on the network, the .doc doesn't even seem to be saving the link
to
the data source - I open the file, no messages asking if I want to run the
query, and opening the Mailings ribbon shows the Finish & Merge button is
disabled. This happens whether my database is a .mdb of .accdb.

Curious. Actually, the /only/ format that works here is the old .doc format.
When I save as either .rtf or .htm, I can open them using a plain text
editor and see that the mailmerge info. has been preserved, but when I
re-open those files, I see exactly the same problem as with the .docx. So I
have to guess that Word is not working in "Compatibility mode" in that case.

Do you still have a Word 2003-format document (e.g. that you saved from Word
2003 (or an equivalent from an earlier version if that is what you had),
pointing to a database in the same location as you have now? Or can you
create one? At least we would then know that the data source info. is in
there, and it's more a question of what Word 2007 does with it?

 

[mariacle]

If I try a .doc that was only ever edited in Word XP, I get a different
message, and this is what led me to try converting everything to the Office
2007 versions in the first place. The error message I get with the XP files
is: "D78907BC.doc is a mail merge main document. Word cannot find its data
source \\hfadc01\shareddocs\...\omega.mdb."

From what I can see of the path to the database, it is correct. The Word
doc the message is referencing is clearly a temporary file, as it is most
definitely not the actual file name, and changes each time I try opening it.

From this point, the only option that works is to remove all merge info and
start over, but then if I save it and re-open it, I get the DDE connection
error that started this whole thread.

 

[Peter Jamieson]

The Word

doc the message is referencing is clearly a temporary file, as it is most
definitely not the actual file name, and changes each time I try opening
it.

Yes, this is how Word, or Vista, seems to work now - it seems to regard
accessing network files as being similar to downloading via Internet
Explorer. I've always rather hoped that we are not in fact dealing with at
least three different views of how to check security (Windows networking's
view, Word's "Trusted locations view", and IE's view, but it's not beyond
the bounds of possibility.

If I try a .doc that was only ever edited in Word XP, I get a different
message, and this is what led me to try converting everything to the
Office
2007 versions in the first place.

Here, it is OK, but there is a difference. If I set up a new document on Win
XP/Office XP using DDE, Access XP opens the .mdb and makes the connection
fine.

However, when I go back to my Vista/Word 2007 environment and open the Word
file, I can see Access 2007 searching for the file dao360.dll. It takes
quite a long time to complete. Then it opens the file and presents the query
prompt. It's difficult to tell whether it actually finds dao360.dll or not,
but it is on my system (in C:\Program Files (x86)\Common Files\microsoft
shared\DAO ). So it is also possible that in some cases Access is "timing
out" looking for that file. In that case, with a DDE connection, I would
normally expect Word to show its "connection is taking longer than
expected - do you want to wait" prompt, but perhaps some other factor is
coming into play here.

I don't know what to suggest at this point. The only thing I can think of is
to try to move towards a solution based on OLE DB rather than DDE, and at
this point I do not know how feasible that is. It would at the very least
involve some VBA coding, some prompts issued by Word, and knowledge of
exactly what parameters were expected by the Access Query.

 

[Al.]

Microsoft MVP's: Any solutions? This is very frustrating. Thank you for
your time and consideration.

 

[Doug Robbins - Word MVP]

Open the query in Access, supplying the information requested by the
parameter and then initiate the mailmerge from Access (if using an Access
report is not feasible).

--
Hope this helps.

Please reply to the newsgroup unless you wish to avail yourself of my
services on a paid consulting basis.

Doug Robbins - Word MVP

 

[Dana B]

We just got Office Plus 2007 at my office and are having this very same issue. We have found that having the database file already open, then selecting it for the merge, the DDE connection works the first time.

If the above doesn't work for you, we've found that on the second try, even if you lock up and and have to restart, the DDE works.

Good Luck. We are finding some new glitch every day!



EggHeadCafe - .NET Developer Portal of Choice
http://www.eggheadcafe.com/default.aspx?ref=ng