This reply assumes that you are actually using Mac Word (some Windows
Word people post in here by accident, but some of the info here is also
relevant for Windows Word).
It isn't completely clear what you are trying to do - if you really want
one row in your Word document for each row in the data source, then you
can either
a. create a Catalog type mail merge with with a 1 row table with as
many columns as you want in your output. Insert 1 mergefield into each
cell in the table. Merge to a new document. Add a header row. Or
b. enable the database toolbar (in Word 2004/2008 you can get to the
necessary options via the View menu). Use the insert database button to
select and insert your data. You can insert it as an updateable field
code. You don't get much control over the formatting so if you need to
make changes automatically you need macro code in Word 2004 or
Applescript code in Word 2008 to modify the table formatting.
However, if the situation is more like the following, a different
approach is needed:
a. your .txt file contains rows for more than one customer - or
whatever, e.g. 1 invoice for customer A, 10 invoices for customer B, etc.
b. you want your merge output to contain 1 page/letter per customer,
with a 1-row table for customer A and a 10-row table for customer B
If it is OK for these rows not to be table rows, then the approach John
McGhie has pointed you to is an optin. You will however find a worked
example by "macropod" at
http://www.wopr.com/cgi-bin/w3t/showthreaded.pl?Number=731107
In my opinion that is probably a better route to take than the one I'm
about to describe, but an even better one is probably to use a proper
database product and report generator to produce this kind of output.
Word's merge is simply not designed for it.
The other way requires that in addition to your existing .txt file
(let's say it's called detail.txt), you have a data source with one row
for each customer containing the data you want to appear for that
customer, and containing a key/ID that relates to detail.text. Let's
assume you have a file like that called master.txt. For example, if
data.txt has a customer ID "A", "B" in a column called ID, then
master.txt would need a column that also contained "A", "B".
Then you
a. use master.txt as the data source.
b. insert a database field (as described above) that inserts data from
detail.txt. When you insert this field, select the columns you need, and
define a filter such as ID = "A"
c. use Alt-F9 (or your Mac equivalent) to display the field codes. The
database field should look something like this:
{ DATABASE \d "pathname:detail.txt" \s "SELECT t FROM
pathname:detail.txt WHERE ((ID = 'A'))" \h }
Then select the comparand A and replace it by a mergefield field that
selects the customer ID from master.txt, e.g.
{ DATABASE \d "pathname:detail.txt" \s "SELECT t FROM
pathname:detail.txt WHERE ((ID = '{ MERGEFIELD ID }'))" \h }
(If the ID is numeric, you would not have those single quotes around it,
e.g. the field would be more like
{ DATABASE \d "pathname:detail.txt" \s "SELECT t FROM
pathname:detail.txt WHERE ((ID = { MERGEFIELD ID }))" \h }
All the {} need to be the special field code braces, not the ordinary
ones on the keyboard.
Then update the field and try merging to a new document. You should see
the rows you want - the problem is still getting the format you want. I
haven't used this technique much on Mac so can only confirm that a
simple example works OK on Word 2008, but on Windows Word the column
layout can change from one customer to the next (sometimes this can be
fixed by adding a \*Mergeformat switch to the database field, but if the
table spans more than one page, all bets are off.
If you are actually using Windows Word, almost all of the above is still
applicable, but...
a. using the DATABASE field approach, you may be able to get away with
a single .txt file as both master and detail, using a bit of Jet SQL to
select distinct customer rows.
b. recent versions of Windows Word put more barriers (e.g. unhelpful
so-called "security" questions) in the way of the { DATABASE } approach
than older versions. In particular, Windows Word can get confused
between the two "data sources" when you merge and have a DATABASE field.
Peter Jamieson
http://tips.pjmsn.me.uk