Re: Merged Word Documents VERY SLOW to open
- From: "Peter Jamieson" <pjj@xxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sun, 29 Jun 2008 09:37:00 +0100
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! :o)
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.
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.
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" <LegalLearning@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:63E91FD0-62B0-4E12-86F5-D72DB81D6135@xxxxxxxxxxxxxxxx
Peter, please see my comments under yours.
--
CLG
"Peter Jamieson" wrote:
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! :o)
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.
--
Peter Jamieson
http://tips.pjmsn.me.uk
"Legal Learning" <LegalLearning@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:36D0010B-B8D3-4208-AC34-137A5C05515D@xxxxxxxxxxxxxxxx
> Peter,
>
> Thanks so much for responding. I was thinking the same thing. Next > week
> I
> will be back in their server and I will see what template is attached > to
> the
> document. Do you think it would be a hard thing to automate through > vba a
> way to attach the correct template or at least the normal.dot?
> -- > CLG
>
>
> "Peter Jamieson" wrote:
>
>> Although Word may spend time looking for a missing/moved data source, >> for
>> mmay data source types it will fail to connect straight away if the
>> source
>> is no longer there. A more likely cause of the perfroance problem is >> that
>> the Mail merge Main Documents are attached to templates that Word can >> no
>> longer find - if you can attach the correct template before resaving >> the
>> document it may speed things up the next time you open. Also, I >> suppose a
>> missing template could be a cause of your missing toolbar problem
>> (although
>> it wouldn't explain why you can't get the toolbar back).
>>
>> Unfortunately there is no real way to programmatically change a Word
>> MailMerge document's data source without opening the document (unless >> the
>> documents happen to have been saved in .rtf, or .html format. It's
>> probably
>> too late now to do what you really needed to do, i.e. programmatically
>> open
>> all the documents while the data sources were still in their original
>> places, save the info. about the data source, then deatch the source >> and
>> programmatically re-attach after the network changes (but frankly, >> even
>> that
>> isn't particularly straightforward). I only mention it in case you can
>> rename anything on the network to recreate the names you had >> previously.
>>
>>
>> -- >> Peter Jamieson
>> http://tips.pjmsn.me.uk
>>
>> "Legal Learning" <LegalLearning@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
>> message
>> news:37CA7E78-F75B-494F-8033-BD7F8E626CAE@xxxxxxxxxxxxxxxx
>> > Using Word 2002.
>> >
>> > Here is what is happening.
>> >
>> > Documents that have been previously merged using an Excel data >> > source
>> > that
>> > lived on a File server. No problems opening these merged documents
>> > UNTIL:
>> >
>> > File Server was replaced. Now these document (thousands of >> > documents
>> > by
>> > the
>> > way) take up to 5 minutes to open. I am sure it is looking for the
>> > data
>> > source on the old file server and not the new one.
>> >
>> > The Mail Merge toolbar is also missing in action. I looked in
>> > Tools/Customize to see if it appears there, under the
>> > Tools/View/Toolbar
>> > as
>> > well as the Letters and Mailing. When choosing Show Mail Merge
>> > toolbar,
>> > it
>> > simply ignores the command and does not display the toolbar.
>> >
>> > After document is finally opened, I have re-associate the document >> > to
>> > the
>> > data source (which is now on the new server) and merge the >> > information
>> > again
>> > and save it and close it. However, it takes the same amount of time >> > to
>> > re-open it!
>> >
>> > I have checked to make sure it is a regular Word document also.
>> >
>> > This is an enormous problem for the company as there are thousands >> > of
>> > documents like this.
>> >
>> > I created a new mail merge document based on the data base that was >> > on
>> > the
>> > old server and is now on the new server. The document opens without
>> > any
>> > issue.
>> >
>> > I appreciate ANY help at all here as we are at our wit's end!
>> >
>> > Thanks for any help.
>> > -- >> > CLG
>>
>>
.
- References:
- Re: Merged Word Documents VERY SLOW to open
- From: Peter Jamieson
- Re: Merged Word Documents VERY SLOW to open
- From: Legal Learning
- Re: Merged Word Documents VERY SLOW to open
- From: Peter Jamieson
- Re: Merged Word Documents VERY SLOW to open
- From: Legal Learning
- Re: Merged Word Documents VERY SLOW to open
- Prev by Date: Re: Can't set display text for hyperlink created in merged Word doc from Excel data source
- Next by Date: Re: URL from .xls into Outlook as "Click Here"
- Previous by thread: Re: Merged Word Documents VERY SLOW to open
- Next by thread: Re: Mail merge is displaying unwanted lines
- Index(es):
Relevant Pages
|
