Creating Unequal Columns

[Joseph N.]

I need to create a catalog-type merge. (The end result will be a
"pleadings index" of documents.) Since I cannot think of any way
to have a table with rows that will auto-generate appropriately (is
there a way?), it seems that columns are the way to go. However, I
cannot create them.... Whatever I do winds up creating multiple
columns according to ruler, but existing or new matter only goes in
the first column; plus, I cannot find a way to navigate to the
other columns. I've tried this with existing text and without
existing text; and filling in the column dialog about every way
imaginable. NPC's are displayed. I do not know VBA. I have not
found the answer in the Help file, either. This can't be so
complicated; what are the secrets? [Word 2002]

 

[Jezebel]

Columns are not the way to go if you're trying to get things in column1 to
line up with things in column 2. Columns are not tables; column 2 is a
*continuation* of column 1, not an independent range.

Beyond that, since you haven't explained what you're trying to do, it's hard
to be helpful.

 

[Joseph N.]

Columns are not the way to go if you're trying to get things in
column1 to line up with things in column 2. Columns are not
tables; column 2 is a *continuation* of column 1, not an
independent range.

Since I respect your expertise from prior posts, I'll take your word for it, but the columns you described are often called "serpentine," "newspaper," or "newsletter" columns. I had in mind "parallel" columns, which are different. Maybe not the best way to go either, but different nonetheless.

Beyond that, since you haven't explained what you're trying to
do, it's hard to be helpful.

Here's the idea:

I have a database that contains various information about a lot of documents. It's a structured database, so the information is in fields. The database is well-designed to interoperate with Word for the purpose of exporting db data into Word documents. (I have created regular merges, but never catalog merges (in Word, anyway), but I'm assuming it won't be too difficult.) The end result should be multiple rows, each of which will have the following information: a sequential number created in Word (i.e., does not exist in the db); then about five variables from the db fields. Ideally they would all fit across a portrait page, but if necessary one particular field could go right below another particular field. Make sense? It would look something like this:

1. Description of doc A Info_X_on_A Info_Y_on_A etc.
2. Description of doc B Info_X_on_B Info_Y on_B etc.

No doubt a table would be the best way to go, but there is no way to know how many rows there will be from one project to another, and even one project will change from time to time. So I need to dynamically generate the number of records at the time of the merge, depending on the number of records being merged.

Whadyathink?

 

[Suzanne S. Barnhill]

Word does not have a "parallel columns" feature. You must use a table. For a
catalog merge, you create a single table row, with one merge field in each
column. If you want the tabular material to be in two or more
newspaper-style columns, you can format the document for columns and then
place your single table row in the first column. The main thing to
understand about a catalog (directory) merge is that any text you include in
the document will be repeated for each record. This means that any headings
(including table headings) that may be needed must either be (a) in the
document header or (b) added after performing the merge.

Since I respect your expertise from prior posts, I'll take your word for

it, but the columns you described are often called "serpentine,"
"newspaper," or "newsletter" columns. I had in mind "parallel" columns,
which are different. Maybe not the best way to go either, but different
nonetheless.

Here's the idea:

I have a database that contains various information about a lot of

documents. It's a structured database, so the information is in fields.
The database is well-designed to interoperate with Word for the purpose of
exporting db data into Word documents. (I have created regular merges, but
never catalog merges (in Word, anyway), but I'm assuming it won't be too
difficult.) The end result should be multiple rows, each of which will have
the following information: a sequential number created in Word (i.e., does
not exist in the db); then about five variables from the db fields. Ideally
they would all fit across a portrait page, but if necessary one particular
field could go right below another particular field. Make sense? It would
look something like this:

1. Description of doc A Info_X_on_A Info_Y_on_A etc.
2. Description of doc B Info_X_on_B Info_Y on_B etc.

No doubt a table would be the best way to go, but there is no way to know

how many rows there will be from one project to another, and even one
project will change from time to time. So I need to dynamically generate
the number of records at the time of the merge, depending on the number of
records being merged.

 

[Joseph N.]

The main thing to
understand about a catalog (directory) merge is that any text
you include in the document will be repeated for each record.
This means that any headings (including table headings) that may
be needed must either be (a) in the document header or (b) added
after performing the merge.

Good tip. I'll try this out in the next few days and post back if
I have further questions. Thanks MUCH for the assistance.

 

[Joseph N.]

For a
catalog merge, you create a single table row, with one merge
field in each column.

Works well, thanks, with one problem and two curiosities. The problem is that merge fields in the header do not seem to work. They are placed and formulated correclty, unless a special procedure is needed for header-based fields, but they do not populate correctly. What appears on the final, merged document are the names of the merge fields. Is there a way to merge into headers?

One curiosity, which does not really matter, is that SEQ fields do not incrementally increase, at least not without any switches. LISTNUM seems to work just fine, though.

The other curiosity is that the available adjustments to table borders seems restricted. For example, there does not seem to be a way to have each row lined top and bottom without also having lines between the cells. To put it another way, the only combination of table and cell borders which seems to work predictably--I think--is "all."

Any assistance you could give on the header problem would be appreciated. And any insight on why SEQ doesn't work might be useful in the future.

 

[Suzanne S. Barnhill]

Merges are not my forte, but I don't think merge fields can be used in the
header/footer (and some other fields don't work anywhere in a merge
document). I think table formatting is one of those things that will have to
be applied after the merge is completed. Your best bet, though, for mail
merge questions, is to post them in the
microsoft.public.word.mailmerge.fields newsgroup, where the merge experts
hang out.

Works well, thanks, with one problem and two curiosities. The problem is

that merge fields in the header do not seem to work. They are placed and
formulated correclty, unless a special procedure is needed for header-based
fields, but they do not populate correctly. What appears on the final,
merged document are the names of the merge fields. Is there a way to merge
into headers?

One curiosity, which does not really matter, is that SEQ fields do not

incrementally increase, at least not without any switches. LISTNUM seems to
work just fine, though.

The other curiosity is that the available adjustments to table borders

seems restricted. For example, there does not seem to be a way to have each
row lined top and bottom without also having lines between the cells. To
put it another way, the only combination of table and cell borders which
seems to work predictably--I think--is "all."

Any assistance you could give on the header problem would be appreciated.

And any insight on why SEQ doesn't work might be useful in the future.

 

[Joseph N.]

best bet, though, for mail
merge questions, is to post them in the
microsoft.public.word.mailmerge.fields newsgroup

Grazie.