Word 2011 Mail Merge bugs RRS feed

  • Question

  • I have been working all day to merge data from a simple Excel 2010 table into a report in Word 2010. The cells with data, the non-zero, non-blank currency figures were not merging correctly. The first few rows of data would merge correctly, but not the remaining fifty rows. Most columns would import correctly, but not all of them. In Excel, I formatted the data cells of the table over and over to remove any stray formatting. That still did not help. Finally it occurred to me that Word 2010 might be using the numeric formatting of the heading cells even though those all contained heading text. It turns out that was the case and the source for hours of infuriating struggle with this idiotic undocumented bug. Even inserting manual formatting codes in the merge template had not helped because for some of the fields, Word just inserted a zero amount wherever there was an actual currency figure in the table. This is an utterly horrible bug which must be fixed. 

    In Word, there is tragically no way to paint merge cell formatting when the merge cells are together in a table layout. That needs to be fixed too. Also I found that all the other more involved data importing methods led to horrible ancient Windows dialogs which should have all been updated, but still looked like Word95 or worse.


    Thursday, January 26, 2012 12:53 AM

All replies

  • We would have to see the actual data to tell whether the is a bug or if there is a way to achieve what you want. 
    Doug Robbins - Word MVP dkr[atsymbol]mvps[dot]org
    Thursday, January 26, 2012 6:27 AM
  • The actual data is confidential financial data which cannot be disclosed in it's entirety.

    Saturday, January 28, 2012 7:21 PM
  • Wiping all cell formatting in the source spreadsheet, including the number formatting for the text cells in the column headers, was required to get Word 2011 to then do a better job of reading all the data cells from data rows. It got further into the merge before it started mangling the data.

    Word just insisted that the values in the currency-formatted cells was somehow a date values, so when in the Word document, absolute merge field formatting for currency was applied to correct for that data importing bug, the defective merge function simply inserted zeros for positive currency amounts.

    One would think that after over 15 years of mail merge feature, Microsoft would make the function far less brittle than this. It's simply very bad programming for uniformly-formatted source data cells in a simple spreadsheet to be treated in a seemingly RANDOM non-uniform manner by the merge function.

    It's also wrong for the merge function to insert merge codes that are created one way without  quotes around the data field name when added using the ribbon, and a completely different way with quotes around the field name when adding through a dialog box.

    All those bugs are so obvious from the most basic testing that (as usual) it calls into doubt both the coding and the testing taking place at Microsoft in the Office division. These most basic of functions should ALWAYS WORK without so much ridiculous intricate intervention---and the functions should work CONSISTENTLY.

    Saturday, January 28, 2012 7:24 PM
  • Hi Mark,

    If you have a mix of data types in the same column (eg text, dates, currency), you risk having the mailmerge filter mis-evaluate some of that data. That's because the filter queries the first 8-15 rows, or thereabouts, to determine what kind of data each column holds. If it finds dates, it might ignore numbers & text. If it finds numbers, it might ignore dates & text. If it finds text, it usually treats numbers & dates as text with no ill effects. This isn't a bug - its a necessary consequence of the default connection method. Changing the connection method to DDE generally resolves that issue, though it can introduce others. Changing data formatting in Excel usually has no effect on a mailmerge.

    Other things that can mess up a mailmerge includes having double-quote characters in the data. In this case, subsequent data fields can get misplaced in the merge.

    Without seeing any of the data, it's hard to diagnose your issues. As for the formatting of the content in the mergefields, that makes no difference one way or the other. Annoying, perhaps, but hardly a bug - since there is no difference in the outcome.

    Paul Edstein
    [MS MVP - Word]
    Sunday, January 29, 2012 2:20 AM
  • How can I have any column headings then for the table being used for merge if those are not text, dates, etc?  That seems to be what Word 2010 trips over even though only the header row had non-numeric content.

    It's not like I'm asking Word to figure out a complex spreadsheet!  All I want is a simple, reliable function to work with the simplest possible data extract table that is pasted into a dedicated sheet as all-values purposely to remove all possible content complications.

    One textual or date-fomatted column id header row should not be too much to ask.

    I might have tried DDE, but I did not see any instructions for that procedure in Word help. In fact, there seems to be very little left in the Word help function compared to the step-by-step instructions that used to be there in Office95, 97, 2000, and 2002.

    I have been using Word and Excel since the DOS versions, and I get more frustrated with all of the unecessary complications that Microsoft adds with each newer version. Data import has become absurdly difficult for the most simple functions, and import of the complex ones have horrible non-prompting dialogs which require perfect file names to be typed or pasted in all at once.



    • Edited by Mark-ilv Sunday, January 29, 2012 3:45 AM
    Sunday, January 29, 2012 3:40 AM
  • How can I have any column headings then for the table being used for merge if those are not text, dates, etc?

    Column headings should always be text. It's the data you need to be concerned with.

    As for the help reference, I've just input 'mailmerge dde' into Word's help function and one of the first references returned was this link: http://support.microsoft.com/kb/320473

    Paul Edstein
    [MS MVP - Word]
    Sunday, January 29, 2012 8:29 AM