Printing a database report

[Andy Lee]

I'm hardly a printing expert, but I do have questions about what's  
going on here...

On Apr 8, 2007, at 8:53 PM, Steve Steinitz wrote:
> That method works but because for each page I have to do hundreds of
> fetches - all the fetches for the whole report - each page takes too
> many seconds to image.

Have you measured to be sure it's the fetches that are taking too  
long and not some accidentally slow drawing code?  You're probably  
right -- I'm just asking as a sanity check.

More importantly, *why* do you have to refetch on every page?  Is it  
because you don't know in advance where the page breaks will be?  I'm  
wondering why you can't fetch once at the beginning and then  
precompute everything that will be needed for all twenty pages.   
Aside from the question of when you execute drawing commands to  
render those twenty pages -- is there some data structure you could  
use to store their content, so you don't have to refetch on every  
page?  For example, if you dataset is a million numbers, and each  
page contains a different weighted average of those numbers, you  
could compute the 20 weighted averages up front and keep them in an  
array, instead of refetching the million numbers each time you print  
a page.

It might help if we understood something about the computations you  
are doing.

> I have a nebulous idea that I could image the
> whole report into a second view or perhaps to pdf or even to a
> low-level graphics-system object... and then, when the printing system
> calls my drawRect, I return rects of that intermediate object, page by
> page.

 From this it sounds like you might indeed have enough data to render  
the whole report with just one fetch?  If so, sure, you could create  
a big view up front that is the size of 20 pages, and pre-image the  
whole report.  But that view will be expensive memory-wise.  I don't  
think it buys you anything in terms of performance.

--Andy