| pblais@odstrategies.org 2007-04-19, 6:55 pm |
| One method I use is to write a source procedure to do the data mining
ahead of the report if I need some special setup or fancy calculations
or formatting or even so I can call the same report in many contexts.
This lets me construct a QUEUE and pass it by reference or perhaps a
GROUP Typed structure that can be passed to a report procedure.
I also use this approach to allow a normal report to be run by tagging
a bunch of records then hitting the print button. I then can make a
queue of the tagged records and send them to the exact same report
that I might use with range limit and or filter called from a report
menu. The idea is that making print bands takes a lot of work to make
them look nice and they often can be recycled for many different
printing needs. It makes the reports look consistent because they use
the exact same bands.
Next I make a report that has only detail bands. Then OMIT out all the
PRINT() commands. At this point you can loop through the queue(s) and
do anything you like. I also make a zero height band with a page after
attribute so I can manually PRINT page breaks. Then you set all the
data values in your detail bands (See SETTARGET) then give the
PRINT(?MyDetail) as you need it printed one band at a time doing all
the work yourself. Using this approach you can do what ever you need
such as running totals or perhaps other operations in hand code. I had
a complex rounding operation I had to do once and nothing else would
work.
This can work quite well if you want to print the same data 4
different ways. One data fetch for 4 reports will be as fast as
possible. If you add a lot of bands you can also reuse the bands and
make as many reports using those same bands as you like. I've done
them so the order, PO, packing list, and Invoice and status reports
are all using some of the same exact detail bands or at least similar
bands. I can update all bands at the same time keeping them aligned
and looking consistent. Report layout can be more expensive than hand
coding. Adding a simple report variation this way means the user can
have version 1 and version 2 with minimal code bloat at minimal cost
to your time. This alternative approach can cause you to write less
code and thus get closer to the goal of being a very lazy and happy
programmer!
On 19 Apr 2007 05:41:18 -0400, "Michael Diamantidis"
<vision@visionca.gr> wrote:
>I wonder what is the best method to create a four pages form report from one
>child table and I want fields from parent file.
---------------------------------------
Paul Blais - Hayes, Virginia
|