This problem occurs only with Windows system.
Tested with:
- XP SP3 > NOK
- 7 Pro x64 > NOK

The result is correct with Debian Squeeze 6.0.5

I have two software identical systems (same Win7 Same OO) which behave differently.  System with 2GHz Sempron and 2GB has trouble actually merging, best results obtained by quitting all other applications and waiting ten seconds, but it manages to send large numbers of emails.  New system with Windows performance index in the 7s and 8GB shows random email sending behaviour as this bug except I've never got it to send more than 6 emails.  Perhaps all this shows basic problem between mailmerge and Windows?  If I cannot send emails to a mailmerge list using OO then I have to find an alternative mass emailer, this is a fundamental business need in 2013 and therefore this bug NEEDS PRIORITY.  It is not difficult to reproduce, my simplest test case with ten records in OO spreadsheet shows the problem every time.

Confirmed on Windows XP

a) Data source:

* Create a spreadsheet with two columns: NAME - EMAIL
* In cell A2 type Name1, select the cell right bottom corner and drag it to cell A51 so that the column is filled with fifty records names Name1 - Name50
* In cell B2 enter a valid email address, and drag it to B51, so that all rows have the same mail adress

Save this spreadsheet and use it as data source for a mail merge in Writer.

b) Mail merge document:

* Insert a database field: select on "Type" - "Mail merge fields", and on "Database selection" select the NAME column from the spreadsheet described above
This way you can test which mails are sent and which not, because every mail will have a "NameN" on its body

* Select the mail merge wizard:

- step 1: Use the current document
- step 2: E-mail message
- step 8: Send merged document as E-mail

E-mail settings:

To: EMAIL  <== the srpeadsheet column
Subject: Dummy subject
Send as: HTML Message

Check "Send all documents"
Press the "Send document" push buttons.


Result
===================

The wizard displays it sent 38 out of 50 mails.

Checking in the mail box where all the mails were sent, the following mails are missing:

Name5, Name9, Name15, Name20, Name22, Name26, Name30, Name32, Name42, Name43, Name49, Name50

Unsent: 12
Total to send: 50
Sent: 38

The problem isn't in the mail service component (mailmerge.py), but in the application code.

On a non-pro build there is an assertion in sw/source/ui/dbui/mmoutputpage.cxx
http://svn.apache.org/viewvc/openoffice/trunk/main/sw/source/ui/dbui/mmoutputpage.cxx?revision=1413471&view=markup#l1340

The file is first exported, with writer8 filter, to sTargetTempURL, then for each merged file an HTML document is created (SfxStringItem aName). When creating an SfxMedium from this file, it has no input stream.

This misbehavior is reproducible also when exporting the document as plain text mail body.

When attaching the document as PDF, some mails have a 0 bytes PDF, this might be a related bug.

(In reply to comment #4)
> The problem isn't in the mail service component (mailmerge.py), but in the
> application code.
> 
> On a non-pro build there is an assertion in
> sw/source/ui/dbui/mmoutputpage.cxx
> http://svn.apache.org/viewvc/openoffice/trunk/main/sw/source/ui/dbui/
> mmoutputpage.cxx?revision=1413471&view=markup#l1340
> 
> The file is first exported, with writer8 filter, to sTargetTempURL, then for
> each merged file an HTML document is created (SfxStringItem aName). When
> creating an SfxMedium from this file, it has no input stream.
> 
> This misbehavior is reproducible also when exporting the document as plain
> text mail body.
> 
> When attaching the document as PDF, some mails have a 0 bytes PDF, this
> might be a related bug.

Does this also explain failure to merge with incomplete display of mailmerge window?

(In reply to comment #5)
> Does this also explain failure to merge with incomplete display of mailmerge
> window?

this explains the error as described in comment 3

What do you mean by "incomplete display of mailmerge window"? Is the same as described in comment 3 or a different bug? The empty (0 bytes length) PDF attachments might be something different, for example.

Not same, on my old system I have had a repeatable fault whereby after clicking Mail Merge Wizard it displays only the frame of the mail merge menu window and usually hangs.  The workaround for this fault was to close all other applications and wait some seconds before initiating the merge.

Still occurs in 4.0 rev. 1488886

Recommend G-Lock Software EasyMail for mass emailing until this is fixed, the free version will probably do for most cases where one would want to use OpenOffice to merge and send emails.

G-Lock Software EasyMail is not free of charge. :-(
Very resticted: no Mac or Linux version is available.

(In reply to oooforum from comment #10)
> G-Lock Software EasyMail is not free of charge. :-(
> Very resticted: no Mac or Linux version is available.

There is a free version which meets my needs and probably those of other small users of mass emailing.  I understand this bug does not occur under Linux (not sure about Mac?) so absence of a Linux version is hardly an issue. But I'd much rather have OO email merge fixed.

set showstopper flag

taking over to indicate that I will have a closer look

I have reproduced the defect on my Windows XP VM with recent snapshot build.

I also reproduced the defect on my Windows 7 machine with AOO 3.4.1 and the recent snapshot build.

But, I was not able to reproduce the defect according oooforum's or Ariel's description on my Windows 7 machine with my local non-pro build. Damn, how should I debug the problem now.

I found the root cause.

The documents created for each Mail Merge instance are using temporary file names. For storing file also temporary file names are used. As figured out, it could happen that the file name for Mail Merge instance collides with internally used temporary file name. In this case the document storing of the Mail Merge instances fails. It looks like that it happens when the machine is fast enough.

Working on a solution.

"orw" committed SVN revision 1498343 into trunk:
121143: SfxMedium - assure that name of internal used temporary file does not...

fixed on trunk for AOO 4.0

It's verified fixed in revision 1499347