crash after mail merge

[Michael Lehmann]

Hi group,

my mail merge is a catalog. In the if-function there is my category
and a table header, after the if a table row with other fields.
Without seing the fields, only the row is seen, not the if. After
merging the main document, it shows all: the first category, the table
header and the row. Now Word hangs, but the task manager shows it is
responding. Only shutting down the task helps.

Microsoft Word 2000 (9.0.6926 SP-3)

http://f2.pg.briefcase.yahoo.com/milehmann

public/klassen.zip

 

[Peter Jamieson]

I don't see the file you mention in your Yahoo! briefcase. Did the upload
succeed?

 

[Michael Lehmann]

I don't see the file you mention in your Yahoo! briefcase.

Hi peter thanks for the hint. The file is now here:
http://de.geocities.com/milehmann/Klassen.zip

Maybe word crashes, because first the context in the if clause is not
visible and after merging it shows up with the first data field. Any
solutions or at least any workarounds, please?

 

[Peter Jamieson]

HI Michael,

I have been looking at these problems. They seem familiar, but so far I have
not been able to identify the exact causes. I am only using Word 2000
9.0.3821 SR-1 here (on Win2k) so you may see different behaviour in SP-3
anyway.

Here what happens is that
a. I start Word
b. I open hauptdokument.doc - the display is in Normal view
c. I merge to a new document
d. I close (and discard) the new document
e. I switch back to hauptdokument.doc
f. When (for example) I press Alt-F9, the Task Manager starts showing Word
consuming all available CPU resource.

The two main factors appear to be:
a. something has to cause Word to start repaginating something. If you
switch off Tools|Options|General|Background repagination (while in Normal
View) and are able to work entirely in Normal view, the problem does not
occur
b. converting the table inside the IF field to plain text also prevents the
problem.

Although neither of those things leads to a practical workaround to your
problem, it may help you look for a workaround (perhaps a change to a table
layout property would make a difference) - I'll have another look myself,
but I cannot do that immediately.

 

[Cindy M -WordMVP-]

Hi Michael,

Maybe word crashes, because first the context in the if clause is not
visible and after merging it shows up with the first data field. Any
solutions or at least any workarounds, please?

I haven't seen the file yet (time problems here, as well) but based on
Peter's observations, something you might try:

Create AutoText entries to hold the tables and place AutoText fields in
the IF fields to reference them. It may be that the "delayed response"
bringing the tables across will prevent the problem.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Sep 30 2003)
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

 

[Michael Lehmann]

Maybe word crashes, because first the context in the if clause is not
Well sorry, it doesn't crash, it hangs.

Thanks Peter for your time so far.

I am only using Word 2000
9.0.3821 SR-1 here (on Win2k) so you may see different behaviour in SP-3
anyway.

This problem occurs on two other computers. I will get the versions
soon. At home I have win98 and I don't think, that my word 2000 has
any "service packs" there.

Here what happens is that
a. I start Word
b. I open hauptdokument.doc - the display is in Normal view
c. I merge to a new document
d. I close (and discard) the new document
e. I switch back to hauptdokument.doc
f. When (for example) I press Alt-F9, the Task Manager starts showing Word
consuming all available CPU resource.

Yes f. is the point. Now I saw, that if the visibility for the fields
are on, word 2000 doesn't hang. (Tools -> Options -> View -> Field
Functions? as I don't have the american word 2000, I just guessed the
words.

The two main factors appear to be:
a. something has to cause Word to start repaginating something. If you
switch off Tools|Options|General|Background repagination (while in Normal
View) and are able to work entirely in Normal view, the problem does not
occur

Yes this works in Normal View, but not in Page Layout? View, because
as I saw now paginating in the backgroud is always checked in Page
Layout? View.

b. converting the table inside the IF field to plain text also prevents the
problem.

Well yes of course, but the layout won't be good.

Although neither of those things leads to a practical workaround to your
problem,

Well that's not true, maybe the settings could do. The problem is,
that it isn't me working on this actually. I wouldn't have a problem
with word hanging. My "customer" doesn't have much experience in word,
and it must work easy for them and they have a BIG problem if word
hangs. I fear, that for them it looks, if I messed up.

it may help you look for a workaround (perhaps a change to a table
layout property would make a difference)

This sounds much better, but I can't think of any properties here.

- I'll have another look myself,
but I cannot do that immediately.

That would be realy nice, thanks.

And again many thanks for your time so far,
Michael

 

[Peter Jamieson]

OK, try the following:

Set the height of the table inside the IF field to a fixed height
(Table|Table Properties|Row|Specify Height in the English language version).

That seems to fix the hang problem here.

For one of the other problems you mentioned (where the preview does not show
what you expect) I think your analysis (that MERGESEQ is not set) is
correct, but if you use MERGEREC instead it should work.

 

[Michael Lehmann]

Set the height of the table inside the IF field to a fixed height

(Table|Table Properties|Row|Specify Height in the English language version).

That seems to fix the hang problem here.

I tried, now as the result I see that word is paginating a lot. If I
cancel fast enough word doesn't hang. Well I realy don't understand,
why word is paginating nor why after cancel there are 3 pages, I can't
see. Didn't it hang on your test (with paginating on)? Than please
send me your main document to my email address.

It could be good to stop word changing the main document after
merging, but how?

For one of the other problems you mentioned (where the preview does not show
what you expect) I think your analysis (that MERGESEQ is not set) is
correct, but if you use MERGEREC instead it should work.

I do not know what you mean with preview. In the example there is no
difference between MergeSeq and MergeRec, both start with 1. MergeSeq
will be better - I think -, because when the user merges the fields
for example above 10, only MergeSeq is 1.

My customer should not see all the fields, just the header the header
table and the row. That would be best. As long one part is in the if,
it isn't showable.

As I see there are three workarounds now:
* no paginating in the background
* field visibility on
* with the fixed table row height, escape paginating fast

Any other ideas? Thanks for your help so far.

Can you help me with a minor problem here? How can I stop two winword
tables merging two one, without having a paragraph between them? As in
my example there is a paragraph between header table and row table.
Without this paragraph these two tables merge in one and the if
statement is corrupt afterwards. But if I have the paragraph between,
after merging all rows are devided with this paragraph.

 

[Peter Jamieson]

That seems to fix the hang problem here.

I tried, now as the result I see that word is paginating a lot.

Yes, sorry, it was doing that here as soon as I switched to print layout
too.

Well I realy don't understand,
why word is paginating nor why after cancel there are 3 pages, I can't
see. Didn't it hang on your test (with paginating on)?

It's clearly an error in Word - it even displays a massive page count in the
status bar at the bottom.

So I had a further look. The other factor is the "Page break before"
formatting of the "Klasse" paragraph. Here (so far!) if I remove that
formatting so there is no page breaking, and change

"Klasse { MERGEFIELD Klasse }

to

"{ IF { MERGESEQ } > 1 "<put a page break here>" "" }Klasse { MERGEFIELD
Klasse }

things seem to go much better. You do not appear to need the changes I
suggested to the table row properties.

I do not know what you mean with preview. In the example there is no
difference between MergeSeq and MergeRec, both start with 1. MergeSeq
will be better - I think -, because when the user merges the fields
for example above 10, only MergeSeq is 1.

Yes. Except I found that { MERGESEQ } had no value when I first opened the
document. I have't re-checked this, but I changed your MERGESEQ comparison
to IF { MERGESEQ } < 2

I do not know what you mean with preview.

I mean "the mode where sample data from the current record is displayed",
not "the mode where some or all of the field codes are displayed with {
MERGEFIELD etc." or "the mode where the field names are displayed within
chevrons <<fieldname>>". But it doesn't really matter. In my experience it
is impossible (or extremely hard) to be completely certain that Word will
display a document in the view that you were using when you closed it.

Can you help me with a minor problem here? How can I stop two winword
tables merging two one, without having a paragraph between them? As in
my example there is a paragraph between header table and row table.
Without this paragraph these two tables merge in one and the if
statement is corrupt afterwards. But if I have the paragraph between,
after merging all rows are devided with this paragraph.

Yes, unfortunately it all comes back to the fact that Word was clearly not
designed to do this, and the workarounds are always frustrating or awkward
for users. I do not know of a good way to eliminate these gaps.

 

[Cindy M -WordMVP-]

Hi Michael,

my mail merge is a catalog.

I'd like to back up a step, here, and ask if this table
you're trying to construct from multiple IF fields could,
in theory, be a query result? IOW, is there a set of query
criteria you could set for the table/data source that would
yield the results you're trying to display?

If the answer is yes, then we may be approaching this the
wrong way.

FWIW, I don't think you'll be able to get what you're
trying to work (unless you keep the paragraph marks). Word
*will* try to merge two adjacent tables, and Word cannot
deal with IF fields across table cells.

If a query can yield the correct set of data, and you
actually want the result in a table format, then what you
need to use is a DATABASE field.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update
Sep 30 2003)
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

 

[Michael Lehmann]

So I had a further look. The other factor is the "Page break before"

formatting of the "Klasse" paragraph. Here (so far!) if I remove that
formatting so there is no page breaking, and change

"Klasse { MERGEFIELD Klasse }

to

"{ IF { MERGESEQ } > 1 "<put a page break here>" "" }Klasse { MERGEFIELD
Klasse }

Yes without page break before, that was good. THANKS

things seem to go much better. You do not appear to need the changes I
suggested to the table row properties.

Yes, but I can't follow why there was a different behavior. fyi, I got
a Hauptdokument.doc which crashes word.

I do not know why the Hauptdokument looks different after the merge.
btw, than I have the view I wanted to have. But, if I change Klasse to
Klxxxasse (for an example) and merge again, the xxx don't show up. If
my customer want to change the layout, that would be a bit difficult.
But it is ok now. Many thanks for your support.

I mean "the mode where sample data from the current record is displayed",

Was it that, what you meant?

I am glad word doesn't hang now, again many thanks, Michael

 

[Peter Jamieson]

Yes, but I can't follow why there was a different behavior.

I can't either. One thing works; the other does not. I think you would need
the Word source code to have a chance of working out why.

Glad we made some progress anyway.

 

[Michael Lehmann]

Create AutoText entries to hold the tables and place AutoText fields in

the IF fields to reference them. It may be that the "delayed response"
bringing the tables across will prevent the problem.

Sorry I didn't get it working. Would you please give an example.

If a query can yield the correct set of data, and you
actually want the result in a table format, then what you
need to use is a DATABASE field.

While reading the word help, that sounds good, but I do not have a
database here, do I? Could the csv file be the database? Please give
an example.

 

[Peter Jamieson]

Create AutoText entries to hold the tables and place AutoText fields in

Sorry I didn't get it working. Would you please give an example.

I tried this too and it did not work. I also tried using INCLUDETEXT fields
to bring in bits of table and that did not work either. I think Cindy was
just making suggestions about what /might/ work.

While reading the word help, that sounds good, but I do not have a
database here, do I?

As far as Word is concerned, "database" is any 2D table it can use as a data
source. So...

Could the csv file be the database?

Yes - enable the Database toolbar, use the Insert Database button, click the
Get Data button and you are in an Open Data Source dialog box exactly the
same as the one you use to connect to a Mailmerge data source. Later, when
you click "insert Data", be sure to check the "Insert data as field" box.

e.g. A field I just inserted here in Word 2000 reads

{ DATABASE \d "C:\\a\\mycsv.csv" \c "DSN=Text
files;DBQ=C:\\a;DefaultDir=c:\\a;DriverId=27;FIL=text;MaxBufferSize=2048;Pag
eTimeout=5;" \s "SELECT * FROM mycsv.csv" \h }

You can probably reduce that to

{ DATABASE \d "C:\\a\\mycsv.csv" \c "DSN=Text
files;DBQ=C:\\a;DefaultDir=c:\\a;" \s "SELECT * FROM mycsv.csv" \h }

The main problems with using a data field are
a. if it uses the same file as the data source ofr a merge, you /may/ get
access problems
b. you do not get much control over the layout

 

[Cindy M -WordMVP-]

Hi Peter,

I think Cindy was
just making suggestions about what /might/ work.

Yes... Grasping at straws, as it were.

Cindy

 

[Michael Lehmann]

The main problems with using a data field are

a. if it uses the same file as the data source ofr a merge, you /may/ get
access problems
b. you do not get much control over the layout

With these points, I do not go further with database. Now I am glad
with the result I have. I hope that there wouldn't be any problems in
production. Thanks again Cindy and Peter for your support. I didn't
know what I had done without your help. Thanks again, Michael