Word cannot resolve mapped DFS directory path in mail merge VBS

[courtview]

I will keep this as simple as possible but am stumped...

I have an application the writes a header (head.tkn) and data
(data.dat) file to a given directory. If I set that directory to a
local directory (C:\Windows\temp), all works as it should.

We have implemented a change where each user will have a private share
within the DFS tree. The UNC path to this share is
\\domain.com\dfs\users\%username%\. The mapped drive for this share is
H.

If I set the data and header file target directory to h:\merge
(\\domain.com\dfs\users\%username%\merge\), the head.tkn and data.files
are written to this location as expected but the merge will fail.

The process is as follows.
-Application writes data/header files
-Application invokes winword and a macro that initiates the merge
-winword opens the merge template (already set up for merge)
-merge template merges the form

With the DFS directory, I get the following dialog:

"{docname} is a mail merge main document. Word cannot find its header
source, H:\MERGE\head.tkn"

When I try and locate the file - h:\merge\head.tkn, the error repeats.
I can clear this error only by removing all merge info. If I do not
close the merge template, manually reset the header and data files and
then run the merge, all is well. It is as if the directory path
H:\merge\ can only be found within the same session that the merge
setup was performed - when using the DFS share.

Hope this makes sence - thanks in advance.

 

[Cindy M.]

Hi (e-mail address removed),

Unfortunately, you neglected to mention which VERSION of Word is involved
in this problem...

I'd say, save the main merge documents with NO data source attached.
After the application opens the main merge document, have it attach the
header and the data sources. In order to get the basic code required for
this, record the manual steps you take in a macro.

I will keep this as simple as possible but am stumped...

I have an application the writes a header (head.tkn) and data
(data.dat) file to a given directory. If I set that directory to a
local directory (C:\Windows\temp), all works as it should.

We have implemented a change where each user will have a private share
within the DFS tree. The UNC path to this share is
\\domain.com\dfs\users\%username%\. The mapped drive for this share is
H.

If I set the data and header file target directory to h:\merge
(\\domain.com\dfs\users\%username%\merge\), the head.tkn and data.files
are written to this location as expected but the merge will fail.

The process is as follows.
-Application writes data/header files
-Application invokes winword and a macro that initiates the merge
-winword opens the merge template (already set up for merge)
-merge template merges the form

With the DFS directory, I get the following dialog:

"{docname} is a mail merge main document. Word cannot find its header
source, H:\MERGE\head.tkn"

When I try and locate the file - h:\merge\head.tkn, the error repeats.
I can clear this error only by removing all merge info. If I do not
close the merge template, manually reset the header and data files and
then run the merge, all is well. It is as if the directory path
H:\merge\ can only be found within the same session that the merge
setup was performed - when using the DFS share.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 17 2005)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question or
reply in the newsgroup and not by e-mail

 

[Peter Jamieson]

The following bit of research I did several years ago may at least help
explain something of what is going on - unfortunately I don't think it leads
directly to a solution other than the one suggested by Cindy Meister.

----------------------------------------------
I don't know much about DFS but simple tests here managed to open a .mdb on
both fault tolerant and standalone DFS roots. However, not being familiar
with DFS I first created a fault tolerant root (\\xyz.local\dfs1 ) and made
a link called link1 to a share share1. i.e. the path name of a .mdb would be
\\xyz.local\dfs1\link1\mymdb.mdb

I then tried creating a standalone root called dfs2 and a link2 to share1,
did not notice straight away that the first part of the address was no
longer \\xyz.local\ but \\machinename, and tried to open
\\xyz.local\dfs2\link2\mymdb.mdb. It was perhaps significant that although
no files were visible in the directory \\xyz.local\dfs2\link2\ WIndows did
seem to regard it as a valid address. Opening the file as
\\machinename\dfs2\link2\mymdb.mdb worked fine here, whether through DDE or
ODBC (I didn't try OLEDB).

The other thing about DFS shares that I suppose is significantly different
from normal Shares is the way that the client PC caches the DFS share name
for so long (using the default setting of half an hour). If someone were to
remove the DFS link /and/ the share, things might start getting messy. But I
can't really see any organisation using DFS doing that as it would
completely defeat the purpose of having DFS.