Chaining Reports?

[bevhoward]

I have a report need that seems like the solution should be obvious,
but it's not... at least to me.

first of two questions;

I have data where I need to run a detail report on about a thousand
clients.

Clients have from one to several hundred related detail records...
i.e. from one to ten pages of details.

I have a report working with a summary band that works for individual
client reports.

I need the summary into on a separate page (to fit in a window
envelope)

However, I need to run this report on all clients with a summary for
each client (on a new page) for every client using a single report
run.

Any tips?

Thanks in advance,
Beverly Howard

[Dan Freeman]

Post by bevhoward
I have a report need that seems like the solution should be obvious,
but it's not... at least to me.
first of two questions;
I have data where I need to run a detail report on about a thousand
clients.
Clients have from one to several hundred related detail records...
i.e. from one to ten pages of details.
I have a report working with a summary band that works for individual
client reports.
I need the summary into on a separate page (to fit in a window
envelope)
However, I need to run this report on all clients with a summary for
each client (on a new page) for every client using a single report
run.
Any tips?
Thanks in advance,
Beverly Howard

Is there a particular reason you can't just call the report repeatedly
in a loop?

I generally avoid single print jobs with thousands of pages when they
can be handled by multiple smaller print jobs because when the printer
eats three pages in the middle I don't want to have to re-print the
whole shootin' match.

Dan

[bevhoward]

Is there a particular reason you can't just call the report repeatedly in a loop? <<

The main reason is that I don't know in advance what printer the user
needs to use.

I tried this but, without using "prompt" the output goes to the
printer specified in the report form... not sure where it will go on
the client (remote) site.

two related questions to that...

how to determine what printer the user selected when the job (report
for the first client) was run and apply that to the subsequent jobs
that the loop will produce so that the user doesn't have to input for
each one.

second, cutepdf is a printer option in this client's case, so the same
need arises... outputting the entire run into a single pdf without
requiring the user to name the pdf for each client.

related info... VFP9

Thanks for the response,
Beverly Howard

[Dan Freeman]

That helps. You have options here.

Post by bevhoward
related info... VFP9

VFP9 has two report writers. <g>

Using the printer stored in the report or using PROMPT is the least
optimal way in ALMOST EVERY CIRCUMSTANCE. :-)

Use Getprinter() to prompt the user for a printer before running the
report. Clear the printer out of the report's environment and use SET
PRINTER to direct output.

To chain together multiple print jobs, see NOPAGEEJECT in the help file
for REPORT FORM. As with most of these things, it probably won't work
*exactly* as you wish but can probably be convinced to do what you
want.

And when managing printers, it's sometimes helpful to use the new
optional parameters on sys(1037).

Dan

Post by bevhoward

Is there a particular reason you can't just call the report repeatedly in a loop? <<

The main reason is that I don't know in advance what printer the user
needs to use.
I tried this but, without using "prompt" the output goes to the
printer specified in the report form... not sure where it will go on
the client (remote) site.
two related questions to that...
how to determine what printer the user selected when the job (report
for the first client) was run and apply that to the subsequent jobs
that the loop will produce so that the user doesn't have to input for
each one.
second, cutepdf is a printer option in this client's case, so the same
need arises... outputting the entire run into a single pdf without
requiring the user to name the pdf for each client.
related info... VFP9
Thanks for the response,
Beverly Howard

[bevhoward]

getprinter() <<

Thanks... that's an important piece I had forgotten... back to the
grind.

Clear the printer out of the report's environment <<

Dumb question... but how? (unchecking printer environment??)

Beverly Howard

[Dan Freeman]

Post by bevhoward

getprinter() <<

Thanks... that's an important piece I had forgotten... back to the
grind.

Clear the printer out of the report's environment <<

Dumb question... but how? (unchecking printer environment??)

Yup! (That's now the default for a newly-created report.)

You can do it in code by USEing the frx and nuking the EXPR field in
the first physical record.

Dan

[bevhoward]

NOPAGEEJECT <<

It now makes sense why I have missed this argument so far... it's not
in the syntax options listed at the top of the "REPORT command" help
page but buried down below in the destination options.

VFP9 has two report writers <<

What are the differences? toggling the set doesn't make any
differences that I can see. At the moment, diving into the
"reportlistener" syntax is a bit too steep for me at the moment.

Thanks again... think I am back on track,
Beverly Howard

[Dan Freeman]

Post by bevhoward

NOPAGEEJECT <<

It now makes sense why I have missed this argument so far... it's not
in the syntax options listed at the top of the "REPORT command" help
page but buried down below in the destination options.

Yeah. NODEFAULT suffered the same fate for many years. Initially it was
only documented deep inside the DEFINE CLASS help topic.

Post by bevhoward

VFP9 has two report writers <<

What are the differences? toggling the set doesn't make any
differences that I can see. At the moment, diving into the
"reportlistener" syntax is a bit too steep for me at the moment.

That's a big topic. There's a LOT in the new report engine.

In general, though, pre-existing reports don't gain anything, and may
not render properly because it changes the rendering engine from GDI to
GDI+. I generally recommend not changing the rendering engine for an
existing report.

For new reports, there's object-assisted rendering, layout, and even
pretty full control over the designer you expose to end-users. TONS of
stuff ... well worth studying just for examining the construction of
it.

Post by bevhoward
Thanks again... think I am back on track,
Beverly Howard

Glad you're off and running!

Dan

[Gene Wirchenko]

On Thu, 28 Oct 2010 07:34:17 -0700, Dan Freeman <***@dfapam.com>
wrote:

[snip]

Post by Dan Freeman
I generally avoid single print jobs with thousands of pages when they
can be handled by multiple smaller print jobs because when the printer
eats three pages in the middle I don't want to have to re-print the
whole shootin' match.

There is the downside that the order of printing is not
guaranteed.

Sincerely,

Gene Wirchenko