Mailmerge with a csv file

[kit]

I'm using Word 2007 to mailmerge a previously created document with a csv
file. When I try, I get:-

XXXXXXXX.docx is a mail merge main document. Word cannot find its data
source, Y:\xxxx_data.csv.

Note the filename is exactly 16 characters long and always the same name.

And when I click "Find Data Source...", I can locate the csv file,
but selecting it only gives me the same dialog again.

I've searched this group for answers. I've seeing posts saying the filename
length is the issue. Is 16 characters too long.

How can I get this to work?

 

[Doug Robbins - Word MVP]

16 characters for the filename should not be too long. How about the drive
letter Y: Is that on the computer or on a network?

--
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

 

[Peter Jamieson]

1. Before you see that dialog, do you see a dialog that says:

Opening this document will run the following SQL command:

SELECT * FROM Y:\xxxx_data.csv

?

Or does the SELECT look more like

SELECT * FROM `txtF0AD0.csv`

?

Or something else (in which case can you tell us what it is?)

2. If you start a completely new mail merge main document and try to connect
to Y:\xxxx_data.csv,
a. does that work?
b. if you can start the Visual Basic editor from the Developer tab, then
display the immediate window, (press control-G within the editor if you do
not see the window) then enter

print activedocument.mailmerge.datasource.querystring

what do you see?

(also

print activedocument.mailmerge.datasource.connectstring
and
print activedocument.mailmerge.datasource.name
)

NB if you do not see the Developer tab in the Word 2007 ribbon, you can
enable it by checking Word Office Button->Word Options->Popular->Show
Developer Tab

3. if you cannot open that data source in a brand new word document, do you
see any error messages or other dialog boxes (e.g. Confirm data source, or
dialog boxes asking about delimiters). Or does the process appear to work
but leaves you with a greyed out "Edit Recipients List" button in the
Mailings tab?

 

[kit]

16 characters for the filename should not be too long. How about the drive
letter Y: Is that on the computer or on a network?

It is a network drive because another system/application generates the csv
file.

 

[kit]

1. Before you see that dialog, do you see a dialog that says:

Opening this document will run the following SQL command:

SELECT * FROM Y:\xxxx_data.csv

No because it's a dam annoying interruption the the end user workflow which
I applied http://support.microsoft.com/kb/825765/en-us

I did re-enable it and it is SELECT * FROM Y:\xxxx_data.csv

2. If you start a completely new mail merge main document and try to connect
to Y:\xxxx_data.csv,
a. does that work?
Yes.

b. if you can start the Visual Basic editor from the Developer tab, then
display the immediate window, (press control-G within the editor if you do
not see the window) then enter

print activedocument.mailmerge.datasource.querystring

what do you see?

SELECT * FROM Y:\xxxx_data.csv

(also

print activedocument.mailmerge.datasource.connectstring
(blank)

and
print activedocument.mailmerge.datasource.name

Y:\xxxx_data.csv

 

[Peter Jamieson]

)K, the reason I asked those questions is because of the possibility that
when the data source was originally attached to the main document, Word
could open it successfully as a merge data source, but subsequently the data
source was populated by data that meant that Word either could not recognise
the file as a valid data source or could not open it using the connection
method that you originally used.

By checking that you can connect with a new Word document you have probably
ruled that possibility out.

FWIW, here I can make this connection using automation with a data file on
Y:\ and a mai merge document on my local hard disk or on Y:\ That's with
Vista 64-bit SP1 and Word 2007 SP1.

So I'm not sure where to go next. Things I would initially consider/try here
are:
a. does the"problem" document have a template attached? Does it also have
the data source attached?
b. if you rename your original mail merge main document, and give the name
to the new test document, does the document open the data source
successfully during your usual process?
c. if you disconnect the data source from the problem document altogether
and reconnect manually (set the mail merge main document type to "Normal
Word Document", then reconnect), does that change anything?
d. if your y:\ drive is on a Win 2003 server, check out

http://support.microsoft.com/kb/834699/en-us

(may be worth it even though that's supposed to be a Word 2002-only problem
e. Amy also be worth checking this, even though it's supposedly a 2003-only
issue:

http://support.microsoft.com/kb/885832/en-us

f. Is the .csv file is being generated immediately before the merge? If so,
there is a possibility that Windows does not think it is closed before Word
tries to open it. Not sure how you can test that, but if you have upgraded
your client OS as well Word, that could be a factor.

 

[kit]

d. if your y:\ drive is on a Win 2003 server, check out

http://support.microsoft.com/kb/834699/en-us

I read this article and I already have those settings set. My network drive
is Linux network share and the article prompted me to try creating and
re-opening the document on a local drive and it worked without issue.

So basically, Word 2007 doesn't like mail merge csv data sources that reside
on Samba based network drives. I'm getting our Linux people on to it. Can
anyone point to any resources that can help our Linux people with this?

 

[Peter Jamieson]

So basically, Word 2007 doesn't like mail merge csv data sources that

reside
on Samba based network drives. I'm getting our Linux people on to it. Can
anyone point to any resources that can help our Linux people with this?

Although "it looks like a Samba vs. MS SMB issue" may be the obvious
direction to head, there have been enough reports of problems with data
sources on network drives in Word 2007 that I would not be completely sure
it is not a local configuration issue (though perhaps related to the network
environment). It's just that I don't know what else to check. However, one
thing that seems pretty clear is that Word 2007 is much more likely to make
local copies of some or all of the files it opens than previous versions of
Word. /If/ that is the case, there may be issues related to e.g. the
permissions on any temp folders it uses, particularly if roaming profiles
are enabled. If you have someone with expertise in that area it might be
worth asking them to have a look as well.

 

[kit]

Get this, the problem is:- I'm running Win Xp Pro with SP3, before I started
working on this project, I had strangely lost my account. I.e. I couldn't
login as myself, but I could login as administrator. Apart from not having an
account anymore, all my files seemed to be in tact. So our system admin guys
recreated my account and everything seemed to work. Except for this mailmerge
issue.

Going to a different machine and do the exact same things for creating and
reusing mailmerge documents with csv files, everything worked like a charm.

It has something to do with accounts/permissions have been changed
mid-stream on my machine.

 

[Peter Jamieson]

Well my best guess is as follows.

When you delete and recreate a user in a domain, despite the fact that the
user may have the same login name and password, if you are using Windows
server the account actually has a new SID (Security ID?). Whether it is
possible to avoid this when using a Samba server rather than a Windows
domain server I cannot tell you.

Various things use SIDs, e.g. access to files, folders and shares is managed
on Windows using ACLs (Access Control Lists) which list SIDs and associated
permissions. A SID is used in the Windows Registry to store per-user
settings on each machine (I think). So there may be various objects on your
own PC, in your own area ("My Documents" etc.) that your old SID has access
to but your new SID does not.

However, at this point I really am out of my depth. I certainly do not know
how you could verify that that is the problem, and how to fix it if it is.
AIUI your domain account can also store a SIDHistory item that /may/ help
overcome some of these problems, and sorting this out /may/ be simply a
question of identifying your old SID and inserting it into your account's
SIDHistory. But I think you will need to find a group with people who
understand more about Windows security to fix this. Or maybe your network
admins know how to do all that but have simply forgotten to do it (or don't
usually need to).