You are slightly unlucky to have discovered mapped fields in this way!
Word recognises two sorts of merge fields: "address" fields, and
"database" fields. If you look at the Insert Merge Field dialog, you'll
see that there are radio buttons for each type.
"database" fields are the fields that are actually in your data source,
whether it is a Word document, Excel, Access table, Access query etc. In
other words, if your data source has a field called "myfield", that's a
database field.
To insert the value of a database field called myfield, you use {
MERGEFIELD myfield }
Address fields are a set of standardised field names that relate to
address components such as street, city, state, zip, country etc. To
insert the value of an Address field such as myaddressfield, you use
{ MERGEFIELD myaddressfield \m }
So where does the data for myaddressfield come from? Well, each address
field has to be mapped to a real database field. Word does this
automatically when it finds database fields with names that it
recognnises. e.g. (theoretical example only) Word might have an address
field called postcode, and if it finds a database field in the data
source called postcode, zip, postbus, etc., it might automatically map
the address field "postcode" to that field. I have never tried to find
out what Word uses as address field names in non-English versions of
Word, or how it decides which database names to map to them.
You can also map (or "match") address fields to database fields manually
- there is a button called match fields in the Insert Merge field
dialog, in the Addressblock field dialog, and the GreetingLine dialog
(AFAICR).
Why go to all that trouble? I assume that the main motivation for
Microsoft was to try to do automatic field matching/mapping to support
ADDRESSBLOCK - a successful design/implementation would mean that users
with data sources that had a set of recognisable field names (e.g., very
probably the data from any address book) could deal with one of the
hardest bits of form letter /label/envelope design by inserting an
ADDRESSBLOCK field. That probably works for quite a lot of users in the
U.S. and perhaps elsewhere, although when ADDRESSBLOCK breaks down, the
only alternatives are really "go back to using individual fields" and
"build the address block in the data source"
The approach is also potentially useful for organisations with
templates/layouts that mainly use address fields but which users are
expected to connect to various different data sources on demand. Using
mapping, they could in principle have a single template and simply
re-map the address fields to database fields as required. In practice,
it wouldn't surprise me to learn that the number of organisations
actually using that approach is very close to zero.
Peter Jamieson
http://tips.pjmsn.me.uk
Peter,
THANK YOU!!! That works! I must not understand what a "mapped" field is .
I assumed that since I was linking to an outside database query, the fields
were "mapped" to that query. I'll have to do a little reading on what
"mapped" fields are. But many thanks. Hours of frustration for me, and you
figured it out easily.
Thanks again,
Robin
Peter Jamieson said:
Hi Robin,
Does your field really have a \m in it? :
{MERGEFIELD CType \m \* MERGEFORMAT}
If so, try leaving that bit out - either
{ MERGEFIELD CType \* MERGEFORMAT}
or simply
{ MERGEFIELD CType }
Same for the other fields.
Peter Jamieson
http://tips.pjmsn.me.uk
Robin wrote:
Peter,
Thank you for the response.
The CType field {MERGEFIELD CType \m \* MERGEFORMAT} is NOT a part of the
address and is from a calculated field in the query - CType:
If([CType2]="C","Corporation",If([CType2]="S","S Corporation", ...) and this
works and shows properly in the "edit reciipient" dialog during the merge
process. Also, as I said, I used the query to create an Access table and
linked directly to that and CType was still the only field that would not
merge. (Shows as a one-character wide blank spot where it should be - no
error, no indication that anything shlould be there...)
As far as the address goes, {MERGEFIELD City \f ", " \m \*
MERGEFORMAT}{MERGEFIELD City \f " " \m \* MERGEFORMAT}{MERGEFIELD Zip \m \*
MERGEFORMAT} I've found I can (thought I couldn't) just hard key the comma
and space so I can deal with that. (The address occurs several places within
the document because it contains a cover letter, an engagement letter to be
signed and returned, and an Organizer.) The CType occurs in the body of all
of these as in: "You, as an officer of your <<CType>>, agree to..." and
titles such as: <<CType>> Income Tax Organizer
Thanks for you help,
Robin
:
1. This one doesn't ring any bells, but...
2. Can you just confirm that you are trying to insert CType using
{ MERGEFIELD Ctype }
and not as part of an ADDRESSBLOCK?
3. What SQL code are you using to construct CType?
2. In the same document when I use City and follow it with a ", " and
State
and follow it with a " " it ignores thos and runs CityStateZip all
together.
THIS OCCURS WHETHER I USE THE \f SWITCH OR JUST AS TEXT IN THE DOCUMENT!
Can you spell out exactly what fields/text you have in the chunk that
doesn't work?
Peter Jamieson
http://tips.pjmsn.me.uk
Robin wrote:
Hello,
In Word/Access 2003 I have a Mail Merge document which pulls from a query in
Access. The query has the fields Company, Address, City, State, Zip, CType
1. Company thru Zip pull from Access fine, but CType does not show up when
I merge the docs. The CType field shows up properly in the "recipient list"
before merging. There are no "blanks" in that field. Because CType is a
computed field I tried changing the default data source in the
Tools|Options|General|Confirm... No effect. I made a table from the query
and tried linking directly to the table. No effect. I created a Word
document from the query and linked to that table. No effect. I don't know
what else to try! Help!
2. In the same document when I use City and follow it with a ", " and State
and follow it with a " " it ignores thos and runs CityStateZip all together.
THIS OCCURS WHETHER I USE THE \f SWITCH OR JUST AS TEXT IN THE DOCUMENT!
I'm frustrated! Can any one help?
Thanks you,
Robin
