Gurus: Report Design Issue ?s

G

Guest

All,

I have a report with a kind of weird design I've been asked to do.
I completed a first version, but it sucks, and I'm looking for a better way
to do this.

The problem is that the report can become a monster, and with the use of a
subreport (more below) as I have, it takes FOREVER to run and print, and
browsing from page to page is just...freking awful.

The report breaks down QA incidents by Plant and then by Cost center
(Production area). So a given page will be for, say,
Plant #1234, Cost Center 2458 (Produciton Line #4)
The first part of the page is the page header, then the detail band prints,
displaying
data like:
incident #4321 5/5/2007 Production worker found foreign object
contamination in main slurry input
Incident #4327 5/8/2007 Water Leak detected above Wrapper machine #2

below the details, in the summary band for the Cost Center group, I have a
subreport which will print things like:

incident # 4321 Worker Lucille Ball was monitoring the main slurry input
to the production line when she observed what appeared to be a "chunk" of
slurry plop onto the fillter screen. By the time she was able to react, most
of the "chunk" flowed through the screen, but she swept the screen area with
her paddle, and slid an object from the slurry flow. A pair of safety goggles
was found to have been the cause of the "chunk" of slurry.

Incident #4327 Worker Sam Spade was monitoring the #2 wrapping machine
around 19:45 hours when he felt a splash on his skin. A few moments later, he
felt it again and began to investigate what could be splashing him. After a
few moments, he glanced on top of the #2 wrapper machine, in time to observe
a fresh drop of water land on the top cowling of the unit. He promptly
informed his supervisor, who checked to see that the source of the water
appears to be a piping joint at ceiling level. Maintenance was called,
identified and remedied the leak within an hour.
Absorbant padding was placed atop the wrapper cowling and change continually
until the leak was resolved approximately an hour later. No product was
contaminated and no production time or materials were lost as the splashes
all were deflected by the front piece of cowling away form the product
inflows and outflows, and the wrapper unit was never leaked into.

That, and typical page# & datestamp page footers is pretty much what the
report looks like.
However, the whole thing performs SO terribly.
I'm looking for a better way to do this, but the end user really wants to
present the data in that mixed brief-list of incidents followed by the longer
explanations at-the-bottom style of report.

The other troubling things about this are:
1) the top list can grow long enough to force the bottom section to another
page
2) the bottom section can be long enough by itself to force another page
3) given the above differences, the list and the items shown on a given page
can get "out of synch with one another" (i.e. Incidents #1234, 1235, 1236,
1237, 1238 show in list at top part of page, but the bottom only shows long
explanatory text for incidents 1234 and 1235, the next page shows
explanations for 1236 and 1237, and the page after that shows 1238. It would
be best to have a way to keep the listed incident #s and their deailed notes
in synch on each page - I presently do not have the details band (the list at
the page top) set to repeat from page to page, since I can't think of a way
to have it break up into appropriate sub-sections based solely upon what fits
together on a page.

Any thoughts, suggestions or alternative approaches to dong this -
especially ones that can perform much better than my present method (using a
single subreport), would be GREATLY appreciated.
 
G

Guest

Since you won't know what the grown size of the explanations will be, it
would be near impossible to keep these together on a page basis. You could
probably group by some field value and place explanations in a group footer.

If your report is taking a terribly long time to print, make sure your
sorting and linking fields are indexed. Also, consider removing the page
numbering. If you are using Page of Pages, get rid of at least the Pages part.
 
G

Guest

Duane,

Take me back to school and teach me the basics again!
You nailed the problem. Both the "Page X of Y" and an unindexed field were
at play here. I took care of both, and the report runs 650% better now.
Thanks DudeDuane! :)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top