Mail merge as a background process using MSAccess forms

  • Thread starter Thread starter Byron
  • Start date Start date
Thanks a lot. But my question is very simple I don't want to launch MS-word or I don’t want the user to see the MS-word opening.

The data, template will be pre-defined and when the Merge button is pressed in the background the merge has to take place and throw the merged output document to an archive folder. Finally just give a confirmation that Merge successful to the user.

Thanks
Sumesh
 
Sorry: I was simply addressing your comment that the link to Albert's page
wasn't working.

--
Doug Steele, Microsoft Access MVP

(no e-mails, please!)



Sumesh said:
Thanks a lot. But my question is very simple I don't want to launch
MS-word or I don't want the user to see the MS-word opening.
The data, template will be pre-defined and when the Merge button is
pressed in the background the merge has to take place and throw the merged
output document to an archive folder. Finally just give a confirmation that
Merge successful to the user.
 
Sumesh said:
Thanks a lot. But my question is very simple I don't want to launch
MS-word or I don't want the user to see the MS-word opening.
The data, template will be pre-defined and when the Merge button is
pressed in the background the merge has to take place and throw the merged
output document to an archive folder. Finally just give a confirmation that
Merge successful to the user.
Thanks
Sumesh

If your question was for 50, or even perhaps 500 letters, then I would
consider you idea reasonable. But to have some process launch some invisible
(or background print) for 5000 letters? That is just not reasonable. Most
printers only hold about 400 letters. And, even the larger heady duty
printers can hold maybe 1000 to 2000 sheets. Regardless, you are talking
about 10 paper tray re-fills. And, even with a good desktop laser printer at
10 pages per min, you are talking about more then EIGHT HOURS of CONTINUOUS
printing (that assumes you are watching hen the paper try empties).
Further,with such large jobs, you will have a VERY HIGH probability of paper
jams and will LIKELY NEED THE ABILITY TO re-start print jobs at a certain
point.

I can just see it now....user clicks button...hum...printer not going,
hum...I just click the button again...hum one more time I will click. (at
this point you send out 15,000 pages to the printer). I can't really even
being to imagine anyone would consider a process that sends 5000 of anything
to printer without some kind of user intervention and controls. With such
large print jobs, VERY OFTEN you will need to re-start or re-print parts of
this job that fails.

I would totally re-consider your concept here. Like I said before,
sure...for 50 letters, or *maybe* 500 letters, I would allow some print job
to go to the printer without showing word, or some kind of user
intervention.

However, 5000 is a VERY large print job, and you likely need some user
intervention and controls here..as a instant one click approach is not even
close to being workable with such a large print job. Further, with such
large amount of printing (10 hours of printing on average desktop printer),
you might want to break the print jobs into 1 or 2 hours manageable jobs.
That way part time people can be hired to man the printers, load paper, load
toner, and un-load paper to run these large jobs. This is big job, and will
requite people and manpower to accomplish. This is not something that one
user can manage in one day of printing time.

As mentioned, these types of big print jobs are likely to crap out and
encounter problems along the way. Often, you will have to re-start. So, you
need to attack such a large print job problem like this with extra care.

The ability to re-start the jobs, and also break out the job into manageable
pieces is likely something you need to consider here.

Further, you don't want word to be attached to the database for such a large
period of time. Thus, if you look at my mail merge, it creates a temp txt
file that word reads. This means that when word has trouble (and with 5000
letters at a time, you will experience increased trouble), at least word
will NOT be attached to the database while it printing. So, if word has
trouble (or the printer), it will NOT take down ms-access if you have to
kill, or stop word. Also, by not allowing word to attached to ms-access, you
are free to use and work on the ms-access database. Further, if you need to
run several printers at the same time, then you can dedicate a work station
and feed/send/share the text files for word to work on. With such large
print jobs you will VERY quickly realize that splitting this job up to go to
multiple printers might be the only way to get the job done in a reasonable
amount of time (say one day for example).

To have word attached and read 5000 letters while it prints (for that likely
10 hours period) is also going to not be a very stable setup all.

I would break out the task into manages word mega sizes of 500, perhaps 1000
letters max. And, then have the people you hire to man and feed the printers
work on a manage print size job. Further, they will be able to start, and
setup the print jobs from word, and not have word attached and reading data
for 10+ hours at a time. Once again, with such large print jobs, you need
some real serous attention as to how these large print jobs will be
accomplish. I can assure that a one button click to background print 5000
letters is not going to make a very happy situation at all.

You can easily pick up 5 bags of groceries with your car today. However, if
you need 5000 bags, then you need staffing, extra trucks, scheduling of the
delivers, extra storage space for hold the results (this list goes on and
on).

The same approach to attacking such large print jobs needs to be done also.
You can not just jump in your car and deliver 5000 bags of groceries, and
you can't just simply print 5000 letters. If you break down the task into
manageable pieces, then the task of delivering 5000 bags of groceries, or
the task of printing 5000 letters is not a problem..but it does need to be
broken down into manageable pieces. This is big big job here.
 
Back
Top