RE: Controlling a fetch loop

We use it a lot where someone else might use OPNQRYF.  IMHO it's much
easier to use SQL for record selection than OPNQRYF.  I think
flexibility and performance gain also.  Really, the number of records
returned is a function of the size of the database as well as the query.
Running the same query on a database containing a few million records
and against a database containing a few hundred million records could
give very different result set sizes.

There's also the hard coded limit issue.  If I put a hard coded limit
into a program it will eventually be reached.  Usually at the most
inopportune time.

Rick

-----Original Message-----
From:
rpg400-l-bounces+rick.chevalier=americredit.com@xxxxxxxxxxxx
[mailto:rpg400-l-bounces+rick.chevalier=americredit.com@midran
ge.com] On Behalf Of Alan G. Campin
Sent: Friday, July 21, 2006 11:04 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: RE: Controlling a fetch loop

In our shop it is common to work with files containing

anywhere from

tens of millions to hundreds of millions of records.  Our SQL

statements

routinely return more than 32,766 records.  I don't think it is

uncommon

to exceed this limit.  It really isn't that large.

I guess my struggle is why a program would end up processing
that many records. I know that databases routinely contain
many more records than that but why with SQL do you end up
processing so many records? In File I/O it could make sense
because you have to read in records to see the values
(Assuming I am not using OPNQRYF) but with SQL, I select only
what I need. Not disputing what you are saying, just
wondering why you would need to process that many records.

Privileged and Confidential.  This e-mail, and any attachments there to, is 
intended only for use by the addressee(s) named herein and may contain 
privileged or confidential information.  If you have received this e-mail in 
error, please notify me immediately by a return e-mail and delete this e-mail.  
You are hereby notified that any dissemination, distribution or copying of this 
e-mail and/or any attachments thereto, is strictly prohibited.