[Not_a_notes_fan]

Hi, Any help gratefully received on this, local charity event. See
http://www.moonlightcolourthon.co.uk

I need to do a merge that pulls a 2 page document from different printer
bins. The first page would be printed on headed paper, the second page is to
fill in content on a preprinted form. The first record (2 pages) prints
perfectly, but the second record (2 pages) is printed only on the preprinted
forms. First page is set to be different to the rest, but it doesnt seem to
apply to mailmerges.

The printer is an HP 2550n with optional 3rd bin installed. Mailmerge is
pulling data from an Access 2003 query.

I am a complete VBA novice so full plain text instructions please!

[Peter Jamieson]

Looks like a nice event :-)

How many copies are you printing?

Sometimes the tray/bin handling does not work as you expect because Word and
the printer drivers seem to disagree for some reason.

An alternative approach would be to use a section break instead of a page
break and set up section 1 to print to one tray and section tray to print to
the other tray. Then test printing direct to the printer. If you want,
output the merge to a new document and verify that each section is
associated with the correct tray.

if that does not work, you'll probably need to use a macro to do "one merge
per data source record", but maybe we can leave that until you've tried the
above suggestion.

Peter Jamieson



"Not_a_notes_fan" wrote in message
...
Hi, Any help gratefully received on this, local charity event. See
http://www.moonlightcolourthon.co.uk

I need to do a merge that pulls a 2 page document from different printer
bins. The first page would be printed on headed paper, the second page is
to
fill in content on a preprinted form. The first record (2 pages) prints
perfectly, but the second record (2 pages) is printed only on the
preprinted
forms. First page is set to be different to the rest, but it doesnt seem
to
apply to mailmerges.

The printer is an HP 2550n with optional 3rd bin installed. Mailmerge is
pulling data from an Access 2003 query.

I am a complete VBA novice so full plain text instructions please!

[Not_a_notes_fan]

Looks like a nice event :-)

Thanks!

How many copies are you printing?

We hope it will get between 3000 and 5000 applicants. The merge letters are
registration welcome packs and personalised sponsorship forms.

Sometimes the tray/bin handling does not work as you expect because Word and
the printer drivers seem to disagree for some reason.

An alternative approach would be to use a section break instead of a page
break and set up section 1 to print to one tray and section tray to print to
the other tray. Then test printing direct to the printer. If you want,
output the merge to a new document and verify that each section is
associated with the correct tray.

I have done as you suggested and merged to a new document. All the sections
now seem to point at the right trays. Test print will be done tomorrow
(working remotely!).

if that does not work, you'll probably need to use a macro to do "one merge
per data source record", but maybe we can leave that until you've tried the
above suggestion.

Rain check that one, just in case!

Peter Jamieson

[Not_a_notes_fan]

I have tried your suggestion which said to use section breaks to no avail. I
have also tried merging to a new document and used a maco found elsewhere on
the forum to seperate the pages still with no luck. The macro is he

Dim i As Long
With ActiveDocument
For i = 1 To .Sections.Count
.PrintOut Range:=wdPrintFromTo, From:="s" & i, To:="s" & i
Next i
End With

Now unsure what else to do.

An alternative approach would be to use a section break instead of a page
break and set up section 1 to print to one tray and section tray to print to
the other tray. Then test printing direct to the printer. If you want,
output the merge to a new document and verify that each section is
associated with the correct tray.

[Peter Jamieson]

OK, try the following macro on a small sample (2 or 3 letters should be
enough for starters), with the mail merge main document set up either as a
single section with a page break (as you originally had it) or as two
sections. Still not sure it will work, but let's see.

Sub PrintOneDocPerSourceRec()
Dim intSourceRecord
Dim objMerge As Word.MailMerge
'Dim strOutputDocumentName As String
Dim TerminateMerge As Boolean

' Need to set up this object as the ActiveDocument changes when the
' merge is performed. Besides, it's clearer.

Set objMerge = ActiveDocument.MailMerge
With objMerge

' If no data source has been defined, do it here using OpenDataSource.
' But if it is already defined in the document, you should not need
' to define it here.

' .OpenDataSource _
' Name:="whatever"

intSourceRecord = 1
TerminateMerge = False

Do Until TerminateMerge
.DataSource.ActiveRecord = intSourceRecord

' if we have gone past the end (and possibly, if there are no records)
' then the Activerecord will not be what we have just tried to set it to

If .DataSource.ActiveRecord intSourceRecord Then
TerminateMerge = True
' the record exists
Else

.DataSource.FirstRecord = intSourceRecord
.DataSource.LastRecord = intSourceRecord
.Destination = wdSendToPrinter
.Execute

intSourceRecord = intSourceRecord + 1
End If
Loop
End With
End Sub

"Not_a_notes_fan" wrote in message
...
I have tried your suggestion which said to use section breaks to no avail.
I
have also tried merging to a new document and used a maco found elsewhere
on
the forum to seperate the pages still with no luck. The macro is he

Dim i As Long
With ActiveDocument
For i = 1 To .Sections.Count
.PrintOut Range:=wdPrintFromTo, From:="s" & i, To:="s" & i
Next i
End With

Now unsure what else to do.

An alternative approach would be to use a section break instead of a page
break and set up section 1 to print to one tray and section tray to print
to
the other tray. Then test printing direct to the printer. If you want,
output the merge to a new document and verify that each section is
associated with the correct tray.

[Not_a_notes_fan]

Thanks for your help Peter. This did work, although the printer itself slowed
the whole process down. It had to stop the motors to change the paper path so
creating a delay that was unbearable

So, I have recreated the documents into Access reports that are called from
the data entry form with a command button. Each time a new record is created
the code saves the record, and outputs the documents.

Thanks again

"Peter Jamieson" wrote:

OK, try the following macro on a small sample (2 or 3 letters should be
enough for starters), with the mail merge main document set up either as a
single section with a page break (as you originally had it) or as two
sections. Still not sure it will work, but let's see.

Sub PrintOneDocPerSourceRec()
Dim intSourceRecord
Dim objMerge As Word.MailMerge
'Dim strOutputDocumentName As String
Dim TerminateMerge As Boolean

' Need to set up this object as the ActiveDocument changes when the
' merge is performed. Besides, it's clearer.

Set objMerge = ActiveDocument.MailMerge
With objMerge

' If no data source has been defined, do it here using OpenDataSource.
' But if it is already defined in the document, you should not need
' to define it here.

' .OpenDataSource _
' Name:="whatever"

intSourceRecord = 1
TerminateMerge = False

Do Until TerminateMerge
.DataSource.ActiveRecord = intSourceRecord

' if we have gone past the end (and possibly, if there are no records)
' then the Activerecord will not be what we have just tried to set it to

If .DataSource.ActiveRecord intSourceRecord Then
TerminateMerge = True
' the record exists
Else

.DataSource.FirstRecord = intSourceRecord
.DataSource.LastRecord = intSourceRecord
.Destination = wdSendToPrinter
.Execute

intSourceRecord = intSourceRecord + 1
End If
Loop
End With
End Sub

"Not_a_notes_fan" wrote in message
...
I have tried your suggestion which said to use section breaks to no avail.
I
have also tried merging to a new document and used a maco found elsewhere
on
the forum to seperate the pages still with no luck. The macro is he

Dim i As Long
With ActiveDocument
For i = 1 To .Sections.Count
.PrintOut Range:=wdPrintFromTo, From:="s" & i, To:="s" & i
Next i
End With

Now unsure what else to do.

An alternative approach would be to use a section break instead of a page
break and set up section 1 to print to one tray and section tray to print
to
the other tray. Then test printing direct to the printer. If you want,
output the merge to a new document and verify that each section is
associated with the correct tray.

[Peter Jamieson]

Thanks for the feedback - but if you're still following the thread, it
sounds as if your Access report is doing exactly the same thing in
principle, i.e. sending one sheet to one tray and the second sheet to the
second tray - so do you have any clues at all as to why it works quickly
when using Access but not (apparently) using Word?

Peter Jamieson


"Not_a_notes_fan" wrote in message
...
Thanks for your help Peter. This did work, although the printer itself
slowed
the whole process down. It had to stop the motors to change the paper path
so
creating a delay that was unbearable

So, I have recreated the documents into Access reports that are called
from
the data entry form with a command button. Each time a new record is
created
the code saves the record, and outputs the documents.

Thanks again

"Peter Jamieson" wrote:

OK, try the following macro on a small sample (2 or 3 letters should be
enough for starters), with the mail merge main document set up either as
a
single section with a page break (as you originally had it) or as two
sections. Still not sure it will work, but let's see.

Sub PrintOneDocPerSourceRec()
Dim intSourceRecord
Dim objMerge As Word.MailMerge
'Dim strOutputDocumentName As String
Dim TerminateMerge As Boolean

' Need to set up this object as the ActiveDocument changes when the
' merge is performed. Besides, it's clearer.

Set objMerge = ActiveDocument.MailMerge
With objMerge

' If no data source has been defined, do it here using OpenDataSource.
' But if it is already defined in the document, you should not need
' to define it here.

' .OpenDataSource _
' Name:="whatever"

intSourceRecord = 1
TerminateMerge = False

Do Until TerminateMerge
.DataSource.ActiveRecord = intSourceRecord

' if we have gone past the end (and possibly, if there are no
records)
' then the Activerecord will not be what we have just tried to set it
to

If .DataSource.ActiveRecord intSourceRecord Then
TerminateMerge = True
' the record exists
Else

.DataSource.FirstRecord = intSourceRecord
.DataSource.LastRecord = intSourceRecord
.Destination = wdSendToPrinter
.Execute

intSourceRecord = intSourceRecord + 1
End If
Loop
End With
End Sub

"Not_a_notes_fan" wrote in
message
...
I have tried your suggestion which said to use section breaks to no
avail.
I
have also tried merging to a new document and used a maco found
elsewhere
on
the forum to seperate the pages still with no luck. The macro is he

Dim i As Long
With ActiveDocument
For i = 1 To .Sections.Count
.PrintOut Range:=wdPrintFromTo, From:="s" & i, To:="s" & i
Next i
End With

Now unsure what else to do.

An alternative approach would be to use a section break instead of a
page
break and set up section 1 to print to one tray and section tray to
print
to
the other tray. Then test printing direct to the printer. If you want,
output the merge to a new document and verify that each section is
associated with the correct tray.

[Not_a_notes_fan]

The delay is still there, but it is not as noticeable! While it is printing
another record is being input, rather than standing at the printer waiting
for a print run to finish.
Effectively I have got away from doing a print job for recent inputs, and so
do not have to have a specific query for the mail merge that takes into
account when the data was entered, and another update query to tell a print
job had been done.

Smoke and Mirrors...

"Peter Jamieson" wrote:

Thanks for the feedback - but if you're still following the thread, it
sounds as if your Access report is doing exactly the same thing in
principle, i.e. sending one sheet to one tray and the second sheet to the
second tray - so do you have any clues at all as to why it works quickly
when using Access but not (apparently) using Word?

Peter Jamieson


"Not_a_notes_fan" wrote in message
...
Thanks for your help Peter. This did work, although the printer itself
slowed
the whole process down. It had to stop the motors to change the paper path
so
creating a delay that was unbearable

So, I have recreated the documents into Access reports that are called
from
the data entry form with a command button. Each time a new record is
created
the code saves the record, and outputs the documents.

Thanks again

"Peter Jamieson" wrote:

OK, try the following macro on a small sample (2 or 3 letters should be
enough for starters), with the mail merge main document set up either as
a
single section with a page break (as you originally had it) or as two
sections. Still not sure it will work, but let's see.

Sub PrintOneDocPerSourceRec()
Dim intSourceRecord
Dim objMerge As Word.MailMerge
'Dim strOutputDocumentName As String
Dim TerminateMerge As Boolean

' Need to set up this object as the ActiveDocument changes when the
' merge is performed. Besides, it's clearer.

Set objMerge = ActiveDocument.MailMerge
With objMerge

' If no data source has been defined, do it here using OpenDataSource.
' But if it is already defined in the document, you should not need
' to define it here.

' .OpenDataSource _
' Name:="whatever"

intSourceRecord = 1
TerminateMerge = False

Do Until TerminateMerge
.DataSource.ActiveRecord = intSourceRecord

' if we have gone past the end (and possibly, if there are no
records)
' then the Activerecord will not be what we have just tried to set it
to

If .DataSource.ActiveRecord intSourceRecord Then
TerminateMerge = True
' the record exists
Else

.DataSource.FirstRecord = intSourceRecord
.DataSource.LastRecord = intSourceRecord
.Destination = wdSendToPrinter
.Execute

intSourceRecord = intSourceRecord + 1
End If
Loop
End With
End Sub

"Not_a_notes_fan" wrote in
message
...
I have tried your suggestion which said to use section breaks to no
avail.
I
have also tried merging to a new document and used a maco found
elsewhere
on
the forum to seperate the pages still with no luck. The macro is he

Dim i As Long
With ActiveDocument
For i = 1 To .Sections.Count
.PrintOut Range:=wdPrintFromTo, From:="s" & i, To:="s" & i
Next i
End With

Now unsure what else to do.

An alternative approach would be to use a section break instead of a
page
break and set up section 1 to print to one tray and section tray to
print
to
the other tray. Then test printing direct to the printer. If you want,
output the merge to a new document and verify that each section is
associated with the correct tray.

[Peter Jamieson]

Thanks - may be useful for someone else one day...

Peter Jamieson

"Not_a_notes_fan" wrote in message
...
The delay is still there, but it is not as noticeable! While it is
printing
another record is being input, rather than standing at the printer waiting
for a print run to finish.
Effectively I have got away from doing a print job for recent inputs, and
so
do not have to have a specific query for the mail merge that takes into
account when the data was entered, and another update query to tell a
print
job had been done.

Smoke and Mirrors...

"Peter Jamieson" wrote:

Thanks for the feedback - but if you're still following the thread, it
sounds as if your Access report is doing exactly the same thing in
principle, i.e. sending one sheet to one tray and the second sheet to the
second tray - so do you have any clues at all as to why it works quickly
when using Access but not (apparently) using Word?

Peter Jamieson


"Not_a_notes_fan" wrote in
message
...
Thanks for your help Peter. This did work, although the printer itself
slowed
the whole process down. It had to stop the motors to change the paper
path
so
creating a delay that was unbearable

So, I have recreated the documents into Access reports that are called
from
the data entry form with a command button. Each time a new record is
created
the code saves the record, and outputs the documents.

Thanks again

"Peter Jamieson" wrote:

OK, try the following macro on a small sample (2 or 3 letters should
be
enough for starters), with the mail merge main document set up either
as
a
single section with a page break (as you originally had it) or as two
sections. Still not sure it will work, but let's see.

Sub PrintOneDocPerSourceRec()
Dim intSourceRecord
Dim objMerge As Word.MailMerge
'Dim strOutputDocumentName As String
Dim TerminateMerge As Boolean

' Need to set up this object as the ActiveDocument changes when the
' merge is performed. Besides, it's clearer.

Set objMerge = ActiveDocument.MailMerge
With objMerge

' If no data source has been defined, do it here using
OpenDataSource.
' But if it is already defined in the document, you should not need
' to define it here.

' .OpenDataSource _
' Name:="whatever"

intSourceRecord = 1
TerminateMerge = False

Do Until TerminateMerge
.DataSource.ActiveRecord = intSourceRecord

' if we have gone past the end (and possibly, if there are no
records)
' then the Activerecord will not be what we have just tried to set
it
to

If .DataSource.ActiveRecord intSourceRecord Then
TerminateMerge = True
' the record exists
Else

.DataSource.FirstRecord = intSourceRecord
.DataSource.LastRecord = intSourceRecord
.Destination = wdSendToPrinter
.Execute

intSourceRecord = intSourceRecord + 1
End If
Loop
End With
End Sub

"Not_a_notes_fan" wrote in
message
...
I have tried your suggestion which said to use section breaks to no
avail.
I
have also tried merging to a new document and used a maco found
elsewhere
on
the forum to seperate the pages still with no luck. The macro is
he

Dim i As Long
With ActiveDocument
For i = 1 To .Sections.Count
.PrintOut Range:=wdPrintFromTo, From:="s" & i, To:="s" & i
Next i
End With

Now unsure what else to do.

An alternative approach would be to use a section break instead of a
page
break and set up section 1 to print to one tray and section tray to
print
to
the other tray. Then test printing direct to the printer. If you
want,
output the merge to a new document and verify that each section is
associated with the correct tray.