Home |
Search |
Today's Posts |
#1
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
MailMerge One Field Ignored/Other Fields \f Switches Ignored
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 |
#2
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
MailMerge One Field Ignored/Other Fields \f Switches Ignored
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 |
#3
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
MailMerge One Field Ignored/Other Fields \f Switches Ignored
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 "Peter Jamieson" wrote: 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 |
#4
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
MailMerge One Field Ignored/Other Fields \f Switches Ignored
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 "Peter Jamieson" wrote: 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 |
#5
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
MailMerge One Field Ignored/Other Fields \f Switches Ignored
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" wrote: 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 "Peter Jamieson" wrote: 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 |
#6
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
MailMerge One Field Ignored/Other Fields \f Switches Ignored
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 Robin wrote: 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" wrote: 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 "Peter Jamieson" wrote: 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 |
#7
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
MailMerge One Field Ignored/Other Fields \f Switches Ignored
Peter,
Well now it makes sense! I was wondering why the \m did not interfere with the Company, Address, City, State, Zip fields...only the CType field. This information will be VERY helpful as this was my first of several Word templates I need to create for our firm. I have been developing an Access database to track work here (VBA and all) and, while I far from an expert, I'm ok with this type of stuff. This is just the first Mail Merge document I've ever tried. BTW, I did look in Word Help after you gave me the solution. I would have NEVER figured out what you just explained using the "help' provided with Word! Thank you again, Robin "Peter Jamieson" wrote: 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 Robin wrote: 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" wrote: 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 "Peter Jamieson" wrote: 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 |
Reply |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Forum | |||
Edit fields with switches | Mailmerge | |||
Is there a way to sort the DB fields in Word's mailmerge field lists? | Mailmerge | |||
Mailmerge with Excel spreadsheet switches columns to display | Mailmerge | |||
Two switches in the one field | Tables | |||
Switches for Fields | Microsoft Word Help |