ANSWER: I woke up this morning thinking about this problem and it occured
to me that if those templates and the master data source (this is the data
source that is linked when they created their master templates) lived
locally
instead of in the workgroup templates directory (which is on their new
file
server now but used to be on their old file server when the problem
documents
were created) they may find the master database and perhaps solve this
issue.
Whew - that was a run on sentence!
)
Yes, I thought a bit more too. I think that's probably one aspect of the
problem.
a. when you are using a .dot to create mail merge main documents and the
..dot is connected to a data source
- the .dot has a connection to the data source
- the /mail merge main/ .doc created from it has a connection to the data
source
- if you mailmerge to a new document, the /output/ created is attached to
the same template as the .doc, i.e. the same .dot
b. the .doc /content/, including the connection, is mostly independent of
the .dot (i.e., attach a different .dot and nothing much will happen to the
document content, although the macros, toolbars and autotexts available may
change and e.g. { TEMPLATE } and { AUTOTEXT } fields may evaluate
differently
c. so for example, changing the .dot so that it has a different data source
is not going to rectify the data source in any of the /mail merge main/
..docs created from it. It should, however, mean that when you open any
/output/ docs with the changed .dot, the template should find the new data
source.
ANSWER: I am not sure what you mean.
Err-my original assumption was that you were not using .dots. A lot of
people work that way.
ANSWER: What do you mean "reintroduce a server with the old name"? Do
you
mean have the new file server be the same name (I think it is but will
have
to check)?
Broadly speaking, what you need is for the templates and data sources to
have exactly the same names as Word was using before. If the server has the
same name, then I wonder if perhaps the "share names" on it have changed -
typically for example, a .dot might have a name such as
\\servername\sharename\pathname\docnam.dot
It's not unusual for a newly ntroduced server /not/ to have the same name as
the old servername, because at a certain point both servers typically have
to be on the network at the same time and they have to have different names.
The problem is that by the time you remove the old server, it is usually
difficult to change the new server's name back. So all references to the old
server no longer work.
I may be wrong, but my guess is that the server name has changed, becuase
that is much more likely to create the delays you are seeing. The thing is
that because software knows that network connections are not necessarily
instant, Word may wait for quite a long time to discover whether a server
called servername is there. However, if servername /is/ there, then
determining whether sharename also exists probably can be expected to be
quite a fast operation.
To fix /old/ documents easily, it's simpler to have data sources in the
/old/ locations. When you automate Word, you do not then get "blocking"
messages that you cannot deal with using automation. You can then update
stuff to point to the /new/ locations. The point here is that you do not
necessarily need "the old server" to do that. What you need is /a/ server
with the right stuff in the right locations. It doesn't necessarily have to
be a separate box - it could for example be a "virtual server" running on
your new server. But it should really be regarded as a temporary device
that's only there to help you make a transition.
However, it may be that your new server still has the same name and the
paths are unchanged (I have seen evidence that Word can /still/ have
difficulty locating stuff in those circumstances, but I have no idea why).
In which case I'm not sure whether automation is going to help much.
No all the documents would be used every day but thousands will
be. There are millions of documents built this way. This is a personal
injury law firm and PI is there only practice area so you can imagine that
most of their documents were built this way. However, only current cases
would be used, which is thousands. These will eventually go away and, of
course, the new cases are originated using the new file server. I created
a
couple using the new file server with the old file server down and they
open
just fine, which is logical.
There are some judgement calls to be made here - if the users are almost
exclsively working with /new/ documents, then changing the templates to
point to the new data sources should fix most of your problems. Otherwise
it's really a question of what the users are willing and able to do.
ANSWER: The problem with this is that there are probably 30 - 40
different
templates that could be the one that the document was created with.
OK, I have now checked and you should be able to get the document name (not
the pathname) of the "old" template from
e.g. ActiveDocument.BuiltInDocumentProperties(wdPropertyTemplate)
AFAICS you cannot get if from ActiveDocument.AttachedTemplate because if
Word does not find the template, it attaches the document to normal.dot
(even though it still shows the full template name in Tools|Templates and
Addins.
ANSWER: Do you think that if those templates were saved locally it would
change the situation? I am thinking not because the path is probably part
of
that link?
I don't think so - I think the problem is the time Word spends looking for a
server that does not exist. But as suggested before, i could well be wrong
about that. I would try it and see what happens.
By the way, the firm uses a DMS (WORLDOX). The Excel database lived on
WORLDOX drive and still does
Is this on a server with the same name as before?
ANSWER: Actually, the reattachment question is not hard because for each
case, they have an Excel Database just for that case. It is not the same
database for all cases. However, it is the same "Dummy" database when the
templates were created. Could that be the issue? This is pretty
complex
and I wish the person that created this could shed some light on it (if
they
could) but they are gone and no where to be found.
I hope the above discussion helps, but there is quite a lot to take in!
I am fair with VBA - not what I would call an expert though - that's for
sure.
I'm not an expert in VBA either.
--
Peter Jamieson
http://tips.pjmsn.me.uk
Legal Learning said:
Peter, please see my comments under yours.
--
CLG
Peter Jamieson said:
First I have been wondering whether or not
a. you have this "template problem" with non-mail merge documents.
Answer: No, all other documents that were created on the old server that
were not created through a mail merge template linked to the Excel
database
are just fine opening with the old server down.
b. there is a place you can put copies of existing templates, at least
temporarily, that Word will find much more quickly
ANSWER: I woke up this morning thinking about this problem and it occured
to me that if those templates and the master data source (this is the data
source that is linked when they created their master templates) lived
locally
instead of in the workgroup templates directory (which is on their new
file
server now but used to be on their old file server when the problem
documents
were created) they may find the master database and perhaps solve this
issue.
Whew - that was a run on sentence!
)
c. whether there are cases where it is the template's data source you
need
to fix, i.e. where you are actually creating new mail merge main document
..doc s starting from a .dot.
ANSWER: I am not sure what you mean.
What I would do would depend a great deal on the overall situation - you
say
for example that there are thousands of documents - and whether or not I
could reintroduce a server with the old name and a copy of the old data
source (and perhaps templates) even if the data is just test data. There
is
also the question of priorities - are some documents needed every day,
and
some only occasionally.
ANSWER: What do you mean "reintroduce a server with the old name"? Do
you
mean have the new file server be the same name (I think it is but will
have
to check)? No all the documents would be used every day but thousands
will
be. There are millions of documents built this way. This is a personal
injury law firm and PI is there only practice area so you can imagine that
most of their documents were built this way. However, only current cases
would be used, which is thousands. These will eventually go away and, of
course, the new cases are originated using the new file server. I created
a
couple using the new file server with the old file server down and they
open
just fine, which is logical.
If I could do that server reintrodcution I'd probably invest some time in
try to create a macro that would look at all candidate documents on a
single
PC and fix them as necessary. You could define "all candidate documents"
as
"all the .doc and .dot files the macro can find", "all the .docs listed
in a
particular file", or whatever. However, because Word's mailmerge
data -source related messages tend to be blocking messages, there is no
guarantee that such a macro could run smoothly.
ANSWER: I agree that this could be dicey and could create more heartache
than what it resolves.
If I couldn't arrange for the old data sources to be there, I'd probably
accept that each fix had to be done manually. In that case what I'd
probably
do is something like
a. create a template with a small macro that tried to attach the correct
template and save and close, and if possible, re-open the document (I'm
not
even sure that a macro can tell what the tempalte name should be),
possibly
with a keystroke defined
ANSWER: The problem with this is that there are probably 30 - 40
different
templates that could be the one that the document was created with.
b. ensure the template is installed as an addin or whatever is needed to
make the macro available
ANSWER: Do you think that if those templates were saved locally it would
change the situation? I am thinking not because the path is probably part
of
that link?
By the way, the firm uses a DMS (WORLDOX). The Excel database lived on
WORLDOX drive and still does and the templates lived (and still do) on a
network drive.
c. tell the users what to do - i.e. when they open a mail merge main
document, they'll have to re-attach the data source (it's how they tell
what
it ought to be that concerns me), use the magic keystrokes to save the
changes.
ANSWER: Actually, the reattachment question is not hard because for each
case, they have an Excel Database just for that case. It is not the same
database for all cases. However, it is the same "Dummy" database when the
templates were created. Could that be the issue? This is pretty
complex
and I wish the person that created this could shed some light on it (if
they
could) but they are gone and no where to be found.
<<
Do you think it would be a hard thing
It depends mostly on your familiarity with VBA.
I am fair with VBA - not what I would call an expert though - that's for
sure. I love all of your ideas, thoughts and comments and welcome more.
You
are very helpful.
