Home |
Search |
Today's Posts |
#1
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
Mail merge using calculation field in an IF field
Hello All,
I'm testing with Word 2003 and when I perform a mail merge that uses a calculation field inside an IF field, the calculation field seems to become unlinked in the merged document. That is, if I have something like this in my mail merge main document ... { = 2+3 } { IF { MERGEFIELD "MyName" } = "Ed" "{ = 2+3 }" "" } .... after the merge the first calculation is still a field but the one in the IF field is just the value 5. If I select it, the right-click menu doesn't have the field options and Alt+F9 leaves it as 5. Is this just Word's "normal" behaviour or am I missing something? Regards. Ed |
#2
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
Mail merge using calculation field in an IF field
This is normal. You have merged the information to create a result.
-- Graham Mayor - Word MVP My web site www.gmayor.com Word MVP web site http://word.mvps.org Ed wrote: Hello All, I'm testing with Word 2003 and when I perform a mail merge that uses a calculation field inside an IF field, the calculation field seems to become unlinked in the merged document. That is, if I have something like this in my mail merge main document ... { = 2+3 } { IF { MERGEFIELD "MyName" } = "Ed" "{ = 2+3 }" "" } ... after the merge the first calculation is still a field but the one in the IF field is just the value 5. If I select it, the right-click menu doesn't have the field options and Alt+F9 leaves it as 5. Is this just Word's "normal" behaviour or am I missing something? Regards. Ed |
#3
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
Mail merge using calculation field in an IF field
It's normal. I've never sat down and worked out exactly when Word completely
resolves the result and when it leaves the field in the document, but I suspect the rules are fairly straightforward. Sometimes it is important to know if, for example, you need to be able to refresh included items (INCLUDETEXT/INCLUDEPICTURE) or if you need a field in a header/footer that evaluates differently on each page in the result document. Peter Jamieson "Ed" wrote in message ... Hello All, I'm testing with Word 2003 and when I perform a mail merge that uses a calculation field inside an IF field, the calculation field seems to become unlinked in the merged document. That is, if I have something like this in my mail merge main document ... { = 2+3 } { IF { MERGEFIELD "MyName" } = "Ed" "{ = 2+3 }" "" } ... after the merge the first calculation is still a field but the one in the IF field is just the value 5. If I select it, the right-click menu doesn't have the field options and Alt+F9 leaves it as 5. Is this just Word's "normal" behaviour or am I missing something? Regards. Ed |
#4
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
Mail merge using calculation field in an IF field
Hi Peter,
It's a bit of a pity that Word behaves like this. Where the original query came from is that one of our clients was trying to create a document to be used for several work types and they had three IF fields which test the work type and conditionally display table A, table B or table C. Each of the tables contains calculations based on data pulled into merge fields from a database. The merge is performed by automation. Occasionally the database data that contributes to the calculations is incorrect and needs to be tweaked in the document post-merge, but since the calculation is no longer a field it doesn't change to reflect the altered data. Thanks for the confirmation. Regards. Ed "Peter Jamieson" wrote: It's normal. I've never sat down and worked out exactly when Word completely resolves the result and when it leaves the field in the document, but I suspect the rules are fairly straightforward. Sometimes it is important to know if, for example, you need to be able to refresh included items (INCLUDETEXT/INCLUDEPICTURE) or if you need a field in a header/footer that evaluates differently on each page in the result document. Peter Jamieson "Ed" wrote in message ... Hello All, I'm testing with Word 2003 and when I perform a mail merge that uses a calculation field inside an IF field, the calculation field seems to become unlinked in the merged document. That is, if I have something like this in my mail merge main document ... { = 2+3 } { IF { MERGEFIELD "MyName" } = "Ed" "{ = 2+3 }" "" } ... after the merge the first calculation is still a field but the one in the IF field is just the value 5. If I select it, the right-click menu doesn't have the field options and Alt+F9 leaves it as 5. Is this just Word's "normal" behaviour or am I missing something? Regards. Ed |
#5
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
Mail merge using calculation field in an IF field
Hi Graham,
Thanks for the confirmation. Regards. Ed "Graham Mayor" wrote: This is normal. You have merged the information to create a result. -- Graham Mayor - Word MVP My web site www.gmayor.com Word MVP web site http://word.mvps.org Ed wrote: Hello All, I'm testing with Word 2003 and when I perform a mail merge that uses a calculation field inside an IF field, the calculation field seems to become unlinked in the merged document. That is, if I have something like this in my mail merge main document ... { = 2+3 } { IF { MERGEFIELD "MyName" } = "Ed" "{ = 2+3 }" "" } ... after the merge the first calculation is still a field but the one in the IF field is just the value 5. If I select it, the right-click menu doesn't have the field options and Alt+F9 leaves it as 5. Is this just Word's "normal" behaviour or am I missing something? Regards. Ed |
#6
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
Mail merge using calculation field in an IF field
Hi Ed,
Yes, the "field language" can be frustrating! You can do things like { ={ IF { MERGEFIELD "MyName" } = "Ed" "2+3" "0" } \## } to retain the calculation. Not sure that would cope with allyour requirements. Peter Jamieson "Ed" wrote in message ... Hi Peter, It's a bit of a pity that Word behaves like this. Where the original query came from is that one of our clients was trying to create a document to be used for several work types and they had three IF fields which test the work type and conditionally display table A, table B or table C. Each of the tables contains calculations based on data pulled into merge fields from a database. The merge is performed by automation. Occasionally the database data that contributes to the calculations is incorrect and needs to be tweaked in the document post-merge, but since the calculation is no longer a field it doesn't change to reflect the altered data. Thanks for the confirmation. Regards. Ed "Peter Jamieson" wrote: It's normal. I've never sat down and worked out exactly when Word completely resolves the result and when it leaves the field in the document, but I suspect the rules are fairly straightforward. Sometimes it is important to know if, for example, you need to be able to refresh included items (INCLUDETEXT/INCLUDEPICTURE) or if you need a field in a header/footer that evaluates differently on each page in the result document. Peter Jamieson "Ed" wrote in message ... Hello All, I'm testing with Word 2003 and when I perform a mail merge that uses a calculation field inside an IF field, the calculation field seems to become unlinked in the merged document. That is, if I have something like this in my mail merge main document ... { = 2+3 } { IF { MERGEFIELD "MyName" } = "Ed" "{ = 2+3 }" "" } ... after the merge the first calculation is still a field but the one in the IF field is just the value 5. If I select it, the right-click menu doesn't have the field options and Alt+F9 leaves it as 5. Is this just Word's "normal" behaviour or am I missing something? Regards. Ed |
#7
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
Mail merge using calculation field in an IF field
Hi Peter,
Neat idea. It works for my simplified test case but I don't think I can apply it in my real-word case because what the IF field contains in the real-world case is a whole table (including calculations) rather than just a calculation. But thanks for the suggestion. Getting Word to "construct" the field on the fly might prove useful in some other situation. We have got at least a couple of ways we can work around the issue - use three work type specific documents rather than one general one. (There isn't much in the document other than the tables so this might even be a benefit, giving flexibility.) Or run a macro after the merge to create the formula fields. (The software used to automate the merge can automatically run a macro.) Thanks for your help. Regards. Ed "Peter Jamieson" wrote: Hi Ed, Yes, the "field language" can be frustrating! You can do things like { ={ IF { MERGEFIELD "MyName" } = "Ed" "2+3" "0" } \## } to retain the calculation. Not sure that would cope with allyour requirements. Peter Jamieson "Ed" wrote in message ... Hi Peter, It's a bit of a pity that Word behaves like this. Where the original query came from is that one of our clients was trying to create a document to be used for several work types and they had three IF fields which test the work type and conditionally display table A, table B or table C. Each of the tables contains calculations based on data pulled into merge fields from a database. The merge is performed by automation. Occasionally the database data that contributes to the calculations is incorrect and needs to be tweaked in the document post-merge, but since the calculation is no longer a field it doesn't change to reflect the altered data. Thanks for the confirmation. Regards. Ed "Peter Jamieson" wrote: It's normal. I've never sat down and worked out exactly when Word completely resolves the result and when it leaves the field in the document, but I suspect the rules are fairly straightforward. Sometimes it is important to know if, for example, you need to be able to refresh included items (INCLUDETEXT/INCLUDEPICTURE) or if you need a field in a header/footer that evaluates differently on each page in the result document. Peter Jamieson "Ed" wrote in message ... Hello All, I'm testing with Word 2003 and when I perform a mail merge that uses a calculation field inside an IF field, the calculation field seems to become unlinked in the merged document. That is, if I have something like this in my mail merge main document ... { = 2+3 } { IF { MERGEFIELD "MyName" } = "Ed" "{ = 2+3 }" "" } ... after the merge the first calculation is still a field but the one in the IF field is just the value 5. If I select it, the right-click menu doesn't have the field options and Alt+F9 leaves it as 5. Is this just Word's "normal" behaviour or am I missing something? Regards. Ed |
#8
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
Mail merge using calculation field in an IF field
Yes, in theory you could also INCLUDETEXT the table, and the INCLUDETEXT
will probably be preserved, but the real probelm is that whatever you do, key information is likely to be lost in such a way that "pre-merge" field behaviour will differ from "post-merge" field behaviour. For example, if the table references MERGEFIELD or bookmarks, but postmerge their names and values are gone. Peter Jamieson "Ed" wrote in message ... Hi Peter, Neat idea. It works for my simplified test case but I don't think I can apply it in my real-word case because what the IF field contains in the real-world case is a whole table (including calculations) rather than just a calculation. But thanks for the suggestion. Getting Word to "construct" the field on the fly might prove useful in some other situation. We have got at least a couple of ways we can work around the issue - use three work type specific documents rather than one general one. (There isn't much in the document other than the tables so this might even be a benefit, giving flexibility.) Or run a macro after the merge to create the formula fields. (The software used to automate the merge can automatically run a macro.) Thanks for your help. Regards. Ed "Peter Jamieson" wrote: Hi Ed, Yes, the "field language" can be frustrating! You can do things like { ={ IF { MERGEFIELD "MyName" } = "Ed" "2+3" "0" } \## } to retain the calculation. Not sure that would cope with allyour requirements. Peter Jamieson "Ed" wrote in message ... Hi Peter, It's a bit of a pity that Word behaves like this. Where the original query came from is that one of our clients was trying to create a document to be used for several work types and they had three IF fields which test the work type and conditionally display table A, table B or table C. Each of the tables contains calculations based on data pulled into merge fields from a database. The merge is performed by automation. Occasionally the database data that contributes to the calculations is incorrect and needs to be tweaked in the document post-merge, but since the calculation is no longer a field it doesn't change to reflect the altered data. Thanks for the confirmation. Regards. Ed "Peter Jamieson" wrote: It's normal. I've never sat down and worked out exactly when Word completely resolves the result and when it leaves the field in the document, but I suspect the rules are fairly straightforward. Sometimes it is important to know if, for example, you need to be able to refresh included items (INCLUDETEXT/INCLUDEPICTURE) or if you need a field in a header/footer that evaluates differently on each page in the result document. Peter Jamieson "Ed" wrote in message ... Hello All, I'm testing with Word 2003 and when I perform a mail merge that uses a calculation field inside an IF field, the calculation field seems to become unlinked in the merged document. That is, if I have something like this in my mail merge main document ... { = 2+3 } { IF { MERGEFIELD "MyName" } = "Ed" "{ = 2+3 }" "" } ... after the merge the first calculation is still a field but the one in the IF field is just the value 5. If I select it, the right-click menu doesn't have the field options and Alt+F9 leaves it as 5. Is this just Word's "normal" behaviour or am I missing something? Regards. Ed |
#9
Posted to microsoft.public.word.mailmerge.fields
|
|||
|
|||
Mail merge using calculation field in an IF field
Hi Peter,
I had tried INCLUDETEXT and what had happened was that both the formula fields in the table and the INCLUDETEXT field itself became unlinked (if the INCLUDETEXT field was inside an IF field, but not if it wasn't). I tried a DATE field inside an IF field and this was unlinked as well. I tried merging the original document using Word 97 and this preserved the formula fields. So I tried a DATE field inside an IF field in Word 97 and got inconsistent results! E.g. if my field was { IF 1 = 1 "{ DATE }" "" } the field was unlinked, but if my field was { IF 1 = 1 " { DATE }" "" } (with the DATE field on the second line) the DATE field remained a field. I couldn't test with Word 2000 but when I tried the original merge with Word 2002 I got the same result as with 2003 - the formula fields were unlinked. Got this with 2007 as well. I'm guessing that the re-write of the merge in 2002 changed how IF fields are handled and (I haven't done enough testing to be sure about this) it looks like maybe any field inside an IF field in the later versions gets unlinked. but the real probelm is that whatever you do, key information is likely to be lost in such a way that "pre-merge" field behaviour will differ from "post-merge" field behaviour. I think you are not wrong. Regards. Ed "Peter Jamieson" wrote: Yes, in theory you could also INCLUDETEXT the table, and the INCLUDETEXT will probably be preserved, but the real probelm is that whatever you do, key information is likely to be lost in such a way that "pre-merge" field behaviour will differ from "post-merge" field behaviour. For example, if the table references MERGEFIELD or bookmarks, but postmerge their names and values are gone. Peter Jamieson "Ed" wrote in message ... Hi Peter, Neat idea. It works for my simplified test case but I don't think I can apply it in my real-word case because what the IF field contains in the real-world case is a whole table (including calculations) rather than just a calculation. But thanks for the suggestion. Getting Word to "construct" the field on the fly might prove useful in some other situation. We have got at least a couple of ways we can work around the issue - use three work type specific documents rather than one general one. (There isn't much in the document other than the tables so this might even be a benefit, giving flexibility.) Or run a macro after the merge to create the formula fields. (The software used to automate the merge can automatically run a macro.) Thanks for your help. Regards. Ed "Peter Jamieson" wrote: Hi Ed, Yes, the "field language" can be frustrating! You can do things like { ={ IF { MERGEFIELD "MyName" } = "Ed" "2+3" "0" } \## } to retain the calculation. Not sure that would cope with allyour requirements. Peter Jamieson "Ed" wrote in message ... Hi Peter, It's a bit of a pity that Word behaves like this. Where the original query came from is that one of our clients was trying to create a document to be used for several work types and they had three IF fields which test the work type and conditionally display table A, table B or table C. Each of the tables contains calculations based on data pulled into merge fields from a database. The merge is performed by automation. Occasionally the database data that contributes to the calculations is incorrect and needs to be tweaked in the document post-merge, but since the calculation is no longer a field it doesn't change to reflect the altered data. Thanks for the confirmation. Regards. Ed "Peter Jamieson" wrote: It's normal. I've never sat down and worked out exactly when Word completely resolves the result and when it leaves the field in the document, but I suspect the rules are fairly straightforward. Sometimes it is important to know if, for example, you need to be able to refresh included items (INCLUDETEXT/INCLUDEPICTURE) or if you need a field in a header/footer that evaluates differently on each page in the result document. Peter Jamieson "Ed" wrote in message ... Hello All, I'm testing with Word 2003 and when I perform a mail merge that uses a calculation field inside an IF field, the calculation field seems to become unlinked in the merged document. That is, if I have something like this in my mail merge main document ... { = 2+3 } { IF { MERGEFIELD "MyName" } = "Ed" "{ = 2+3 }" "" } ... after the merge the first calculation is still a field but the one in the IF field is just the value 5. If I select it, the right-click menu doesn't have the field options and Alt+F9 leaves it as 5. Is this just Word's "normal" behaviour or am I missing something? Regards. Ed |
Reply |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Forum | |||
mail merge: printing multiple pages, or field calculation error | Microsoft Word Help | |||
Why do I get Field Calculation Error when I Mail Merge? | Mailmerge | |||
What causes field calculation errors in mail merge? | Mailmerge | |||
How to identify and correct mail merge 'field calculation errors' | Mailmerge | |||
Mail merge field different in datasource & insert a field menu | Mailmerge |