Re: Large Master/Detail/Detail Reports

From: Paul Dorsey <pdorsey_at_dulcian.com>
Date: Mon, 24 May 1999 01:38:14 GMT
Message-ID: <a4223.2187$wu1.1551_at_news.rdc1.nj.home.com>


[Quoted] First, let me state my two axioms for Oracle Reports: 1) The product is as deep as anything on the market. If you can imagine what [Quoted] you want it to do, it can do it. Furthermore, it can be done with a minimum [Quoted] of time and effort.

2) The product is about as user friendly as a Wolverine with a tooth ache. [Quoted] Simple reports are easily done with the wizard but reports such as you describe in your post require someone with very deep talent with the product. Such talent is rare in the industry.

I do not recommend going to another product. With the kind of report you [Quoted] are talking about, any product will give you headaches.

Now to your problems.
My comments are embedded below.

--
Paul Dorsey
Dulcian, Inc.
www.dulcian.com
212 595 7223

>
>The first problem for a report of this size occurs in creating the default
>layout. Initially, Reports places all the detail groups to the right of,
>rather than below, the master group. To avoid the REP-1212 error, the Page
>Width must be increased to an artificial number, such as 50 inches. Then,
>the developer must manually drag and drop the detail frames and items to
>their desired location below the master frame, and the Page Width can be
>restored to 8.5 inches.
For such as report you should be laying out your report 1 frame at a time. Use the additional default layout tool in the layout editor.
>
>After several hours, the layout can be manipulated to the desired
>configuration, so the design problems can be overcome. But there are
>runtime problems that cannot be overcome. When the master frame encloses
>all of the detail frames (the standard arrangement), its height in the
>layout editor may be larger than the standard physical page height of 11
>inches.
I have never had this problem, sorry. I have always been able to squeeze things onto one page. If I had your report, I bet I could figure out something though.
>
>As a workaround, I restructured the hierarchy of the master frame and
detail
>frames so that the master frame did not enclose the detail frames. Instead
>of a parent-child relationship between the master group and detail groups,
>all groups were siblings. This structure reduced the height of the master
>frame in the layout editor to 3 inches, thus allowing me to set Logical
>Vertical Panels back to 1, and eliminating the unnecessary blank pages at
>the end of the report. However, the price I paid for this structure is
that
>I can no longer use a summary counter in the master group to count the
>number of occurrences of each detail group and print a "No detail records
>retrieved" message when there are no detail records retrieved, because of
>the REP-1314 message.
Why couldn't you use a formula column to support this? I can probably live with this limitation, but there
>is another problem that I cannot live with.
>
>Because of the large number of fields in the detail groups, I cannot use a
>"tabular" format, with the label above the field. All the fields will not
>fit on one line on 8.5 inch wide paper. Instead, I must use a "form"
>format, with the label on the same line and to the left of the field.
(This
>is not a limitation of Reports -- it is a function of the large number of
>fields in the detail groups.) The result is that for some detail groups,
>one instance may require as many as 6 inches vertically to print. Of
>course, if an instance begins to print near the bottom of a physical page,
>it may not fit entirely on that page and will roll over to the next
physical
>page. The Vertical Elasticity property ostensibly handles this situation.
>Setting this property to Variable will print as much of the object as
>possible on the first logical page, and if necessary, complete the object
on
>the following logical pages.
>
>The problem is that when this "rollover" occurs, there is a blank space at
>the top of the next physical page. This blank space is equal to the amount
>of the repeating frame that printed on the previous physical page. For
>example, in my report an instance requires 6 inches. If it prints 4 inches
>at the bottom of the first page, then there is a 4 inch blank space at the
>top of the next physical page before the remaining 2 inches are printed.
>Obviously, this blank space in the middle of the report is unacceptable.
If
>the Vertical Elasticity property is set to Fixed, then the object will not
>attempt to print unless the entire instance will fit on the page; it will
>begin printing on the next page. This results in a 4 inch blank space at
>the bottom of the first page. Either way, there is an unacceptable 4 inch
>blank space in the middle of the report. I suspect that there is no way to
>avoid this, because the Vertical Elasticity property operates on logical
>pages, not physical pages.
There is ALWAYS a way. :) The problem is that the fields are anchoring to each other. Then when the frame rolls over to the next page, the field anchors to the top of the frame and BINGO, a big gap. If you plave an enclosing frame around each field and lable combination with vertical elasticity set to variable, the gap goes away.
>
>These various design and runtime problems have led me to conclude that
>Reports is not equipped to handle large master/detail/detail reports. But
I
>know I can't be the first person to try to produce a report like this. Has
>anyone found a way to overcome these problems? I don't have any experience
>with other report writers, so I don't know if other products have these
same
>problems or not. I welcome any comments or suggestions.
Todd, you don't need to dispare. Just keep plugging away. I have never found a problem yet I couldn't lick in Reports.
>
>Todd Owers
>toddo_at_gcr1.com
>
>
Received on Mon May 24 1999 - 03:38:14 CEST

Original text of this message