Publisher can't find mail merge data source

[Peter Kinross]

I have a series of MS Publisher docs that I mail merge print from Access. Access builds a table of addressees in Word and opens the Publisher docs that are linked to the Word table as a data source. Problem; 5 days ago I re-installed Office 2003 and now none of the Publisher docs seem linked to their data table in Word. The docs know that they are supposed to be linked, but can't link. When I open the Publisher doc, it tells me that the doc can't find the data source. When I try to manually point to the Word doc that contains the table data source, Publisher very politely tells me:
This operation cannot be completed because of dialog or database engine failures. Please try again later.
Later doesn't do anything either, even a re-start does nothing.
How do I re-link the Publisher docs with their perfectly good data source that opens on its own without any problems?

[HansV]

Which version of Windows are you using? If Windows XP:
Use the Microsoft Data Access Components (MDAC) Utility: Component Checker to determine which MDAC version is installed.
Extended instructions are given in How to check for MDAC version.

Next, visit MDAC Downloads. If a newer version of MDAC than the one you have is available, install that.

[Peter Kinross]

Thanks Hans. I am using Win 7 and the component checker won't work with it, (I tried)

[HansV]

Do you have other versions of MS Office on this PC? Or have you had them in the past?

[Peter Kinross]

In the past I tried the current version of Office (yuck!), but have done a clean install of Windows, Office and everything else since then. So I there are no remnants on the current setup.

[HansV]

I'm afraid I'm out of ideas (except reinstalling everything once more...)

[Peter Kinross]

Thanks for your ideas Hans. I will keep searching

[Peter Kinross]

Maybe this might help the thinking process.
I copied the data source from Word to Excel. Unlike the Word data source, I can point the Publisher doc to this data source and it works.

(I build the data doc and call the Publisher doc from within Access and I don't want to re write the code to use the above work around unless absolutely necessary.)

[HansV]

What is the full path and name of the Word document that fails as data source?

[Peter Kinross]

Full path & name of the Word doc data source.

C:\Access\Insuranc\MergeDocs\LakeEdgeEnv_Cards\BirthdayEnvelopesData.doc

This has worked seamlessly for years. But not since getting Windows update working.

[HansV]

Thanks - another avenue shut off. I found a suggestion that a period in the path/filename (except before the extension) might cause this problem, but that's clearly not the case here.

Does it make a difference if you shorten the filename and/or move the document up in the folder tree, say to

C:\Access\EnvelopesData.doc

so that the path becomes shorter? (I know it shouldn't, but I'm just grasping at straws now)

[Peter Kinross]

Grasping at straws has got me out of countless difficulties.( When dealing with Microsoft stuff, grasping at straws often becomes the first avenue <gr>.)

Tried moving Publisher & Word docs to C:\Temp and renaming data doc to BDayData.doc. No dice.
Bummer!
Another thought. The data doc is also the data doc for another Word doc that print merges envelopes. This Word print merge and the Publisher print merge are called from Access, one after the other within the same procedure. The Word print merge of the envelopes still works fine. It just fails when print merging the Publisher doc

But sincere thanks Hans for the additional mental gymnastics.

[HansV]

It's a very strange problem. Word and Publisher share much of the mail merge engine, so it's puzzling that Word can mail merge using this data source while Publisher can't.

Do you have a particular reason for using a Word document as data source instead of an Access table or query?

[DaveA]

Is this Word source set up using tables?

From the help on Publisher 2007

The Catalog Merge task pane can use a variety of data source formats. If you don't already have a data source to use for your merge, you can generate one in Publisher. You can also create a data source in a Microsoft Office Excel worksheet or in a Microsoft Office Word table.

The data fields (data field: A category of information that corresponds to one column of information in a data source. The name of each data field is listed in the first row (header row) of the data source. "PostalCode" and "LastName" are examples of data field names.) that you include in your data source correspond to the merge fields (merge field: A placeholder for text or pictures that you insert into your publication. Information from a data source (such as a name, address, or image) is inserted in each merge field. You can format, copy, move, or delete a merge field.) that you insert into your catalog merge template.

When you set up your data source, create a column for each type of information, such as the item name, the stock number, and the price. Each row, or record, corresponds to the information for one item.

[Peter Kinross]

Thanks for the thoughts guys.
Reasons for using Word as a data source:
I use a table in Word as a data source to print a series of envelopes. As this data source has been already set up by the Access VBA procedure, I reasoned that I may as well use it for the publisher docs too. I could have used an Access table or query, but years ago, in the days of limited memory, using Access as a data source started another instance of Access. Way back then I wanted to avoid the second instance of Access.
I could re-write the procedure to use an Access table as the data source, which, these days, would be more efficient. But I dearly would love to know why this weird behavior. Something is wrong and that makes me uneasy. But uneasiness is probably second nature to anyone using Microsoft stuff on a heavy basis. <gr>

[HansV]

A second instance of Access will be started (at least in Access 95/97, I never tried it again later) if you use DDE to connect to the database AND if you have set an application title for the database in Tools | Startup Options...
I always use ODBC to connect to the data source; this is faster and doesn't start a second instance of Access. The only disadvantage is that you can't use queries that rely on VBA functions.

[Peter Kinross]

Yes I changed the code to use ODBC a few years ago, but left the building of the data source in Word because it worked flawlessly. The queries that generate the data list do use functions and calculated fields, that is why I said that my best option is to use an Access table.
But doing that doesn't fix the underlying problem. As with so many of Billy G's products, it looks like I will have to use the workaround.
Thanks anyway guys - much appreciated.
(Hans isn't it past your bedtime?)

[HansV]

(Hans isn't it past your bedtime?)

Yep, I'm going to sign off soon.