Mail Merge - Filters adding condition not originally specified

[bobcharest]

This worked correctly in my previous version of office (2003)



I'm creating mail merge documents using an Excel doc as the data source. In Word, when I specify the following criteria for fields and conditions:

Mailed is blank
and Print equal to X

then click on OK to close the dialog, Word creates the following:

Mailed is blank
or Mailed is blank
and Print equal to X

This invalidates the conditions I originally specified, as there are many entries where the Mailed field is blank and I testing for the originally specified set of conditions only.

This bug is reproduceable - should I go to Microsoft with it in some way?

Thanks in advance,
Bob Charest

[macropod]

Hi Bob,

I've seen this reported before, but I've not seen a solution.

As a workaround, you could abandon the filter and use SKIPIF fields in the document, coded along the lines of:
{SKIPIF {MERGEFIELD Mailed} = ""}
and:
{SKIPIF {MERGEFIELD Print} = "X"}

Note: The field brace pairs (ie '{ }') for the above example are created via Ctrl-F9 - you can't simply type them or copy & paste them from this message.

[bobcharest]

Hi Paul,

Thanks for the workaround. As this one case is my test to see what labels we might have printed but not mailed, I can try to implement the SKIPIF fields. I haven't coded fields like that into a document previously, so this will be an experiment on my part.

Do you think that Microsoft would be responsive to fixing the bug? That's what I would really like to do.

Thanks for your reply, and I'll post how I make out... if I can do it If not, I'll ask more questions.

Best regards,
Bob Charest

[macropod]

Originally Posted by bobcharest

Do you think that Microsoft would be responsive to fixing the bug?

I hope so, it's a fairly significant issue for some users and seems related to testing for blanks - AFAIK the rest of the filtering works OK, in which case you could leave the Print filter in place and just use the SKIPIF test for the Mailed field.

[bobcharest]

Originally Posted by macropod

I hope so, it's a fairly significant issue for some users and seems related to testing for blanks - AFAIK the rest of the filtering works OK, in which case you could leave the Print filter in place and just use the SKIPIF test for the Mailed field.

Hi Paul, Thanks again for the help. I'm realizing (as I'm learning to insert the fields) that I don't think SKIPIF will work for me. I actually want the records that match both of my conditions to be present in the merged document so I can check our mailings. To skip the records where both conditions are met would give me the opposite of what I want I think. Am I wrong about this?

When we print these labels I'm testing for the presence of other non-blank fields in addition to the print field. This give us labels for business associates, clients, personal aquaintances, etc. I agree that the problem seems to be related to testing for blanks, as after the field that has been tested for "is blank" the software inserts an "or" operand, invalidating the argument.

Thanks again,
Bob Charest

[bobcharest]

Trying to initiate a bug report to Microsoft now...

[macropod]

Originally Posted by bobcharest

Hi Paul, Thanks again for the help. I'm realizing (as I'm learning to insert the fields) that I don't think SKIPIF will work for me. I actually want the records that match both of my conditions to be present in the merged document so I can check our mailings. To skip the records where both conditions are met would give me the opposite of what I want I think. Am I wrong about this?

Hi Bob,

With a 'Print = X' filter, only the records that have the 'X' would be passed through to the SKIPIF field for 'Mailed' testing. Conversely, with a 'Print <> X' filter, only the records that lack the 'X' would be passed through to the SKIPIF field for 'Mailed' testing. The 'Mailed' SKIPIF test can then be based on the presence or absence of something in that field, via:
{SKIPIF {MERGEFIELD Mailed} = ""}
or:
{SKIPIF {MERGEFIELD Mailed} <> ""}

FWIW, if you want to test for multiple conditions using just a SKIP field, you can code the field along the lines of:
{SKIPIF{={IF{MERGEFIELD Mailed} = "" 1 0}*{IF{MERGEFIELD Print} = "X" 1 0}> 0}
and:
{SKIPIF{={IF{MERGEFIELD Mailed} = "" 0 1}*{IF{MERGEFIELD Print} = "X" 0 1}> 0}
etc if both conditions must be met, or:
{SKIPIF{={IF{MERGEFIELD Mailed} = "" 1 0}+{IF{MERGEFIELD Print} = "X" 1 0}> 0}
and:
{SKIPIF{={IF{MERGEFIELD Mailed} = "" 0 1}+{IF{MERGEFIELD Print} = "X" 0 1}> 0}
etc if either condition must be met.

[macropod]

Hi Bob,

An interesting discussion with MS Tech Support! Unless your copy of Office isn't fully updated, I very much doubt that any MS Tech could actually 'fix' it. For your $99, at best they might give a different workaround (eg coding the filters with vba, which is entirely do-able), but that's not a fix. And, given that it's a software fault (reported elsewhere in discussion groups), you shouldn't be charged for it.

[bobcharest]

Originally Posted by macropod

Hi Bob,

An interesting discussion with MS Tech Support! Unless your copy of Office isn't fully updated, I very much doubt that any MS Tech could actually 'fix' it. For your $99, at best they might give a different workaround (eg coding the filters with vba, which is entirely do-able), but that's not a fix. And, given that it's a software fault (reported elsewhere in discussion groups), you shouldn't be charged for it.

Hi Paul,
My copy is at the latest fix level, and I couldn't agree more. While the person on the other end of the chat might have been more helpful for an actual "end-user" type question, the responses were sparse, it seemed. Between the $99 charge which would not have changed the release of the software and the somewhat dis-interested tone of the responses, the image of Microsoft as being unconcerned with the actual quality of the product was re-inforced for me. But, the general public has been the beta test group for many years now.

I'm going to test the coding examples that you were so kind to provide and post results. I really appreciate your help!

Best regards,
Bob Charest

[Micha Elyi]

Word 2002 (XP) had the bug Bob Charest describes and today I see it again on my shiny new licensed and fully updated copy of Word 2013. My source data is in an Excel spreadsheet.

I've been Bingin' on the Internet but haven't found a solution yet, just workarounds. I appreciate the help from those who have suggested workarounds but I would like the root cause found and fixed. A workaround will only have me wondering "Why did I do this strange thing?" a month from now.

[macropod]

Cross-posted at:
http://answers.microsoft.com/en-us/o...=1402725563033
http://answers.microsoft.com/en-us/o...b-62a49aacf04a

For cross-posting etiquette, please read: http://www.excelguru.ca/content.php?184

It seems you more interested in making a fuss about this than to contributing anything to resolving the problem. Please don't resurrect old threads just to have a whinge.