They are standardised field names. To use them, you have to "map" them or
"match" them to the real names in the data source, which are the "Database
Fields". Word uses a "\m" in a MERGEFIELD field to indicate that it is using
an "Address Field".
The theory is that...
By using them, you can always use the same names in your mail merge main
documents, no matter what the names are in the data sources you connect to.
So for example, suppose you have one Excel file with columns Title, Surname
and Job, and another one with essentially the same type of data but with
columns called T,S and J, you could use the "Address Fields" Courtesy Title,
Last Name, and Job Title in your Mail merge main documents (e.g. {
MERGEFIELD "Courtesy Title" \m } etc.), and in one case map
Courtesy Title to Title
Last Name to Surname
Job Title to Job
and in the other case map
Courtesy Title to T
Last Name to S
Job Title to J
Word does some of the mapping automatically when you connect to a data
source, because it recognises some variants (e.g. perhaps First Name,
FirstName and First_Name).
I quite like the theory, but in practice,
a. doing the mapping is a pain. For example, I would want to be able to
store a simple set of mappings in a file along with the data source
b. I don't think I've ever encountered anyone actually using this approach,
at least as it seems to have been intended. People who use the ADDRESSBLOCK
and GREETINGLINE fields are likely to /have/ to do the mapping, because
those fields rely on the same underlying notion, but in most cases they are
likely to be using Outlook fields which Word mostly recognises
automatically.
Peter Jamieson
