[StargateFanFromWork]

"Peter Jamieson" wrote in message
...
Has your Mail Merge Main Document definitely just got a 4x20 table?

Yes.

If you look beyond page 1 of that document, are there definitely no
additional rows?

Yes. Just the one page. I always view in print layout mode so easy to see
when there's more than one page. And it's only been one page since the
beginning. Weird.

Peter Jamieson

"StargateFanFromWork" wrote in message
...
"Peter Jamieson" wrote in message
...
So here's the problem. 5167 has 4 columns of 20 rows (for a total of
80 labels). The original target label file has the standard 8x20. But
the merged docts all come out at 8x21! I don't know how to fix this.

The layout I get when I choose the 5167 option is 4x20. My best guess is
that at some point along the way, you may have selected a table row and
duplicated it by accident to make a 4x21 layout.

I start out with an 4x20 doct. as well. I put a typo there, btw, the end
result comes out 4x21, not 8x21! So my main word doct. (yes, or
"template", I never have kept the terms straight, Word or not), starts
out as 4x20 but the merged doct. comes out 4x21 each time. I've
re-created the template 3 times now and not once did I duplicate a table
row, so don't know why this additional row is sneaking in g.

To see what's happening, it may help to show the table gridlines - try
Table|Gridlines.

Always have the table gridlines showing, btw. Thanks.

User: USER
UIN: UIN
Country: COUNTRY S/N: SN
Model: Model P/N: PNNext Record

Okay, Word is opposite in that way. The Next Record appears at the
top of the 2nd record onwards rather than at the end of the first record
onwards, except for the last record. Got it.

Some Word-oriented terminology:
a. Mail Merge Main Document: the layout (or "template", but that does
not necessarily mean a Word .dot template) - i.e. how you want your
output to look, and where to put each item of data
b. Mail Merge Data Source - the data you are going to merge into the
Mail Merge Main Document
c. Mail Merge Destination - could be a Destination Document or a
Destination Printer, etc.

Yeah-yeah lol. I've never kept the terms straight. I just know myself
what I'm working with even after all these years of doing other work
besides word-processing g. It's like riding a bike, though, it all
comes back to one even if the app is a different one.

In the Mail Merge Main Document, the first label cell should have:

User: USER
UIN: UIN
Country: COUNTRY S/N: SN
Model: Model P/N: PN

Subsequent label cells should have something like:

Next RecordUser: USER
UIN: UIN
Country: COUNTRY S/N: SN
Model: Model P/N: PN

Changed it to this format where the Next Record is at beginning
starting with cell #2 onwards. Nothing has changed, though. The labels
are still coming out okay, same as before, and all in the right sequence,
I'm just getting in an extra table row at the bottom of each page of the
merged doct. (there are a total of 4 pages, so 3 of them are 4x21 while
last page is only partially filled as it doesn't fill up an entire page).

I'm stumped ... how 'bout you?

Cheers. D

Peter Jamieson

"StargateFanFromWork" wrote in message
...
"Peter Jamieson" wrote in message
...
Can you spell this out a bit? I read and re-read, but wasn't sure what
exactly you are seeing. Is the extra row at the very end of the
output, and what exactly does it contain (a duplicate of the last row
of labels?)

Yes, certainly. And thanks for the question; it helped to look at this
from a different angles to try to figure out what's wrong.

Admittedly, I've not done many mail merges in Word. All that I used to
do in my years as a word-processor when WP was the standard. I hadn't
actually looked at the data, so hadn't realized that I was just getting
one record repeated over and over g. My extensive WP experience
helped out and I remembered that there, too, we had to put and "End
Record" field in. Once I did that, this Word mail merge worked
properly in that way, too.

So here's the problem. 5167 has 4 columns of 20 rows (for a total of
80 labels). The original target label file has the standard 8x20. But
the merged docts all come out at 8x21! I don't know how to fix this.

I just thought of this, here's what in each cell in the original target
label file:

User: USER
UIN: UIN
Country: COUNTRY S/N: SN
Model: Model P/N: PNNext Record

I bet you that this will make much clearer what I'm doing wrong. Each
and every cell has the above coding but I'm not sure if this is
completely right. Perhaps I'm missing something here, too, that is
generating labels with an incorrect # of rows.

In WP, I vaguely remember that the last field on the page needed an
extra code (next record, or end record, or somesuch). Is this the
same for Word?

In Word 2000, the main thing to get right is "no { NEXT } field in the
first label cell on the sheet, one { NEXT } field at the beginning of
each label cell after that", bearing in mind that some cells in some
layouts - such as 5167 - have "spacer" columns of cells that should
not have anything in them.

I might have misunderstood the above paragraph, but when I removed the
"Next Record" (doesn't show up as "{ NEXT }" for me. I'm using an
Excel file that I used to put in the fields, btw), in the first cell,
the first 2 cells in the merged label output were repeated. So that's
not what you're referring to, obviously g.

Re the spacer columns, yes. There is nothing in those columns at all
and they remain empty after the merge. So okay there.

Is it possible to tell what I'm doing wrong judging from the coding
above??

Thanks. D

Peter Jamieson

"StargateFanFromWork" wrote in message
...
Okay, however non-intuitive this solution would be, it is doing the
job, thank goodness. I'm still having one problem. I'm getting an
extra row at the bottom of the merged end document. The original
target document has the correct spacing at the bottom, but the merged
doct. puts in an extra row. In WP, I vaguely remember that the last
field on the page needed an extra code (next record, or end record,
or somesuch). Is this the same for Word? Pls advise. D

"Doug Robbins - Word MVP" wrote in message
...
Leave labels alone and achieve the space that you are after by
changing the formatting of paragraphs - Left and Right Indent, Space
Before and Space After.

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

"StargateFanFromWork" wrote in message
...
I absolutely must have cell margins that are at about 0.05" around
the insides of Avery-sized labels #5167. Before changing the
margins, the pages of labels are aligned and positioned correctly.
The instant I change them to 0.05", the rows all become misaligned
and a standard sheet has a row pushed off to the next page. About
halfway throught the first page, the labels contents are printing
half off the labels.

The text before and after the merge in no way is too much for each
cell and I made sure that the "automatically resize to fit
contents" option is not selected in the table options of the table
properties so I'm at a loss to figure out what is going on. The
labels are not always printing correctly from sheet to sheet as,
I'm sure most with experience have found, different batches of
labels come out slight differently placed. I've not done much mail
merge or label work as was the case back in my old word-processing
days, but at the time I had working templates with table margins
that worked for any label batches that came along. Through trial
and error one eventually finds the margins that work to the
maximums of label production offset and 0.05" is about the minimum
to accommodate these offsets. Certainly, 0.08" (tEventually a
margin is found that accommodates all slight variations between
label stocks. But if I can't change the margins and retain the
integrity of labels, then I'm stuck. Does anyone know what to do in
this situation? I don't know what else to look at. 0.05" is not
even my preference for label margins. In WP days, I'd use the
standard WP size of 0.05" and I used to use 5167 even back then.

Stuck and hoping someone here knows a good solution to this.
Thanks! D