max number of subreports

[Former Member]

hi -- I'm wondering if there's a maximum number of subreports that can be included in a main report. I saw someone else

on the forum trying to confirm this... they thought it might be 256, which would be more than enough for my purposes.

Does anyone know for sure? My reports are only 1 page each, though I'm not sure that would matter.

Thanks,

Carol

[Former Member · Accepted solution]

About 60. I'm currently at 10, with no problems, formatting, performance, or otherwise.

I guess I just go for it, as having as few reports as possible is our goal... and if we need to

break it up into more than 1, so be it.

Curious -- when you say "the fewer the better", is it actually the subreports that are the issue,

or the number of sections required to integrate them all? I could incorporate all the contents of

each report into a section, I suppose, but it would be an ugly amount of work... and may not

ultimately be of benefit....

Thanks,

C

[Former Member · Accepted solution]

Just thinking out loud here, and this is just my humble opinion, so take it for whatever you find it's worth...

I really don't understand the objective of "as few reports as possible". IMHO, the more the merrier - for a couple of reasons.

First, putting all of those reports into one has to increase run time, particularly if the person running it only needs to see the data on "report 47". 59 other reports need to be generated just to get that one. Plus, that person has to find "report 47" buried within the 60.

Another reason to keep them separate would be security reasons. This may or may not be a concern in your organization today, but it may become one in the future. By having separate reports, accessibly by only the people that need to know the information on them, security can be controlled easily. This is, in fact, a "best practice". And, if it applies to you, a Sarbanes-Oxley requirement.

Lastly, what is the real benefit of having one monstrous report containing everything but the kitchen sink, as opposed to 60 separate reports (organized logically in folders)?

As I said, just thinking out loud...

Carl

[Former Member · Accepted solution]

hi Carl -- I'm glad you're thinking out loud.

First, security isn't an issue, but I certainly see your point.

It actually is common that users need to run the reports individually, and we do have them in that format also.

Each report is then integrated into the main one as a subreport, re-imported each time the main report opens,

in case there have been modifications.

The motivation for having one report is that,at the end of the year, an "Annual Report" is created for the

powers that be -- it includes all of the individual reports, numbered pages, etc.

-- Performance on the annual report isn't an issue -- only on the reports when run individually.

-- A scheduler could handle the job of automatically running all of the reports for the Annual Report (who would

want to do that?), but they do all need to be integrated into a single PDF. Is there is a way to do that

simply (not having to individually import each file, every time the Annual Report needs to be generated) such as:

-- bulk drag and drop of individual PDF files, with predictable order,

-- a one-time setup of the master PDF, using something like ordered "links" that point to each

indiviidual report PDF file; the individual PDFs would have to be re-read when the master PDF is opened

I'm not aware of anything like this, but would be happy to hear that you are!

Thanks,

Carol

[Former Member · Accepted solution]

Personally, I see this as a maintenance nightmare. Every time a report changes functionality (which around here is nearly daily, it seems :->) the Annual Report needs to be updated as well. It seems somewhat error prone as well (but maybe not that bad...).

My initial thought on integrating each report into a Master "Annual Report" would be to use OLE to create a master document referencing the annual versions of the reports. Open the master document, and it'd pull all of the other reports into it.

Scheduling the reports to run automatically is really trivial with InfoView: Tell the scheduler to run the report monthly (or whatever) for the prior month and put the resulting report at a specific file location. Set it up once, and you don't have to worry about it. If you make these auto-run reports as Object Packages, then changes that need to be installed are easier. (Things like schedule and destination won't have to be ported to the new version. You just have to copy in the new report, set the parameters and format, then reschedule the package.) This is how we do it...

HTH,

Carl

[Former Member]

Not sure about a max, but the less of them you have the better the report will work. How many do you think the report will need ?