Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
DiscussionsAccessExcelInfoPathOutlookPowerPointPublisherWord
DirectoryUser Groups
Related Topics
Outlook ExpressInternet ExplorerWindowsMS Server ProductsMore Topics ...

MS Office Forum / Word / Programming / August 2007

Tip: Looking for answers? Try searching our database.

mailmerge ends prematurely w/o error

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
christopher.allen - 24 Aug 2007 15:45 GMT
I have Word VBA code that basically:

    opens a main doc
    for each *.txt
      opens it as a datasource
      mailmerges it
      saves it
      Adobe ConvertToPDF
      closes it
    next

Sometimes, the mailmerge ends prematurely without merging all the
records.  No indication at all of any problem.  These are 500-record
datasources, the first record being the header info.

What really bothers me is that sometimes it works, sometimes it doesn't.
 Sometimes it'll do this on smaller datasource files too.  It occurs on
the mailmerge, not the ConverToPDF, sometimes on the first datasource.

Anyone experienced this?  I'll be happy to supply more details if you want.

Word 2000, Windows XP SP2.  Also reproduced with Word 2003.
Peter Jamieson - 27 Aug 2007 17:27 GMT
Just an observation... my own experience of doing this kind of thing (which
is rather outdated now) is that Word probably has at least one memory leak
that will appear no matter how you split up a large merge. It may be worth
trying to do multiple merges using a script that starts word, does the
merge, closes word and so on, but that's not particularly easy either.

Unless you are having problems with specific .txt files...

Peter Jamieson

Signature

Peter Jamieson
http://tips.pjmsn.me.uk

>I have Word VBA code that basically:
>
[quoted text clipped - 19 lines]
>
> Word 2000, Windows XP SP2.  Also reproduced with Word 2003.
christopher.allen - 28 Aug 2007 20:46 GMT
Thanks for your comments, I've tried the one-merge-per-invocation and
that helps.

I'm running Word from a perl script, and I thought there might be some
funny business going on with this setup, another reason I tried the
one-merge-per-invocation thing.  The perl script basically does this,
once per data source file:

    my $wrd = Win32::OLE->new('Word.Application');
    $wrd->Run($MACRO);
    $wrd->Quit();

Another thing I thought of:  my system has both Word 2000 and 2003
installed, so I'm wondering if there's any interference between the two
installations.  Running on a single-install system seems to help.

Also, each of my data source files contains the header record as the
first line.  Does this ring any bells?

Thanks again.

> Just an observation... my own experience of doing this kind of thing
> (which is rather outdated now) is that Word probably has at least one
[quoted text clipped - 6 lines]
>
> Peter Jamieson
Peter Jamieson - 28 Aug 2007 21:30 GMT
> Also, each of my data source files contains the header record as the first
> line.  Does this ring any bells?

Not really, but it's possible that WOrd is using different methods to read
the .txt files - with Word 2003 it would be a choice between its internal
text converter, and an OLE DB provider. Although I would expect that it
would /always/ read the same file using the same method, if your file
content is changing over time, that method might change for each file from
merge to merge. Precisely why that would cause a problem I do not know, but
perhaps for example one method is leakier than another.

However, the chances are that that's a red herring.

Signature

Peter Jamieson
http://tips.pjmsn.me.uk

> Thanks for your comments, I've tried the one-merge-per-invocation and that
> helps.
[quoted text clipped - 27 lines]
>>
>> Peter Jamieson
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.