I now know what the problem is but not the cause although there is an easy solution.
I created a table and populated it with the data from the view then copied the report to use the new table. First thing that I noticed was a significant improvement in the speed of the report being run. Even allowing for the time it takes to populate the table (now a temp one) and run the report it is taking less than half the time it took running off the view directly. That didn't solve the problem however. What did solve it was to remove the SHOW_CANCEL_DIALOG OFF from my print command options. Now I can run the report with a where clause that selects every name starting with each letter of the alphabet except for "V" without displaying the page count box. (So the individual reports for 0-9, A-U & W-Z are quite happy not displaying the box. All are smaller than the report for "V".) Jumping to conclusions again it looks as if there is some unknown (to me, at any rate) factor that affects the page count. I've got more pages in other reports than in this one so it's not a simple count. There are 6 breakpoints in this report but only 2 or 3 in others so I'd guess that some combination of breakpoints and page numbering fails. Regards, Alastair. ----- Original Message ----- From: "Alastair Burr" <[EMAIL PROTECTED]> To: "RBG7-L Mailing List" <[email protected]> Sent: Friday, February 25, 2005 7:55 AM Subject: [RBG7-L] - Re: Problem with reports (continued...) > Thanks, Larry, I'm going to try projecting the data from the view to a > table and running the report against the table. I can't think why it would > make any difference but who knows. > > I don't think there's much point in trying to overcome that sort of limit > for the page number if that is the problem. In many ways it ought to be > reduced to save trees!! > > Regards, > Alastair. > > > > ----- Original Message ----- > From: "Lawrence Lustig" <[EMAIL PROTECTED]> > To: "RBG7-L Mailing List" <[email protected]> > Sent: Thursday, February 24, 2005 6:37 PM > Subject: [RBG7-L] - Re: Problem with reports (continued...) > > > > > The solution is easy: it seems that there is a point at which the page > number > > > fails. Printing to the screen (thanks, Larry) showed me that the report > > > "stopped" at page 32,693. Reducing the number of page breaks solved the > > > problem. > > > > 8-bit signed int being used for the page number? That may not be > > overcome-able. > > > > > The report, however, stops at around record > > > 12,800 on page 5158 yet when I break the report into two "halves" there > is no > > > problem. This is consistant both on screen and to a file - so I tend to > > > exclude any file problems. > > > > > > Has anybody got any further ideas that I might try? > > > > Look for a similar problem -- maybe overruning a variable type in a SUM > > variable, or something? > > -- > > Larry > > >
