Managing Reports that Are Being Combined into One Report

[Fried Elliott]

I have 4 different self-contained reports I would like to variously combine
into one continuous "print job" based on various parameters chosen by the
user off a master print control form.

Currently, the record source for each report is set using the openarg:
parameter to a .OpenReport method created using values gathered on this form,
and there are 3 different types of record sources that can be created for
each report, each of which is in effect a different primary header or
grouping field. All this is buried in a function call that for each report
essentially figures out how to setup the report and print it.

In thinking through the method of "combining reports embedding each as a
subreport on a master report, with appropriate headers, grouping, and
linking"...

With (currently) 4 different reports being combined under (currently) 3
different primary groupings (and therefore different primary link fields),
I'm concerned that this approach is going to result in a combinatorial
explosion of versions of these various master and subreports since if I
understand it correctly, I would need to create three versions of a master
(each with their different primary link field) and four different versions of
each report as a subreport since although I assume I could set the child link
property I don't believe I can use the openargs: trick to set the record
source for each subreport on the fly.

I may not understand entirely how this is going to play out but before I go
charging down this path and start hacking away on my current (beautifully
working and hard earned) reports and functions, I would be interested in
hearing if I have thought this through correctly and appreciate any thoughts
or suggestions concerning how to manage this potential explosion of reports
and subreports I am anticipating as a result.

Many thanks in advance!

Fried Elliott
Dallas

 

[Fried Elliott]

Well, typing it out forced me to see at least one hole in my understanding.
Please bear with me as I attempt to correct my explanation of my lack of
understanding. LOL

The four reports each have a different primary header and each have three
different queries (or "modes of use") that can be used to filter (or "select")
this primary header. One of these three different queries is chosen based on
parameters selected on the form by the user and the chosen query is passed to
the report as the value for OpenArgs: of a DoCmd.OpenReport invocation.

Now, each report has the same possible three "modes" although the query used
for each report in each mode is neccesarily different, keeping in mind their
primary headers are different by design intent. In use, if I were to select,
for example, "Mode #2" and then hit the print button for each of the four
reports, they would each produce the proper report given the context "Mode
#2" and it is the four reports generated in this context I wish to combine
into one continuous "print job".

SO... the four reports do not share a primary header (or link field); but
rather, they share the "intent" used to generate their underlying record
sources. Viewed in this light, I'm now thinking the "combine PDFs" approach
may be the only alternative.

I guess what I really want is functionality similar to DoCmd.Echo for a
printer. Something like:

DoCmd.SpoolPrint True
docmd.openreport "Report_1", acViewPreview, , , , OpenArg1
docmd.openreport "Report_2", acViewPreview, , , , OpenArg2
...
DoCmd.SpoolPrint False
DoCmd.PrintOut

and voila! One print job would get dropped into the printer queue (or one
preview window opened or one PDF file generated or whatever).