Re: Print Total Pages in Report

*sigh*  Okay, here is the fallacy with your proposed method, Bill.

I want to print an aging report.  How many pages am I going to have in total?
Obviously, that depends on the number of outstanding invoices, which I won't
know until I get to the end of the program, requiring me to go through the data
*twice*, once to count the number of records I'm going to print, the second time
to actually print them.  Fine right?  Well, what if, while I'm going through 
counting these, while the program is half way down the list, someone goes into
the A/R program and enters some new cash received.  

Now, when I go through the program a *second* time to actually print them, the
number of pages has changed.  Or perhaps someone did an invoice production run
in the middle.  Any number of things.  Any way, I can not just count the number
of records, because I just don't know how many I'm going to print.

That is where the discussion thread came in we've pointed you too, different 
ways
to work around this, from writing records to temporary file first, to writing to
a spool file with a place holder, to ... you get the picture.  

There are many possible solutions proposed, and many possible problems brought 
up.  I'm just so glad David gives us the archive :)

Regards,

Jim Langston

Douglas Handy wrote:
> 
> Bill,
> 
> >Are you a programmer or just make up excuses to not do things?
> 
> I'll be diplomatic and just point out my reply was to this proposed method:
> 
> >Wow ... why not just take the total number of records to be processed and
> >divide it by the number of records printed to a page?
> 
> Hopefully by now you've thought about it and realized the fallacy in that
> proposal.  If not, I strongly recommend you read the thread others have 
>pointed
> to in the archives.
> 
> >Your program is going to print a detail and total line for a reason, when
> >that reason happens ADD 2 TO THE COUNTER.
> >
> >Duh...
> 
> Are you suggesting a two-pass approach to determine "when that reason happens"
> or an algorithm (Select count(*) ...???) in *INZSR to calculate how many times
> the "reason" happens?  Either way, we've already moved away from your original
> proposal, which is exactly the point -- the original proposal doesn't always
> work.  If you read the referenced thread, you'll see it is not as simple as 
>your
> second proposal either.
> 
> Shall I continue to beat this dead horse?
> 
> Neigh, neigh, I say.
> 
> Doug
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: david@midrange.com
> +---
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---