|
but in practice, to need to read in more than 32766 records would seem unreal. That would say they is something wrong with the SQL.
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. We have a defacto standard read loop that does a multiple record fetch repeatedly until all result records have been read. It functions much the same as blocking does. The number of records read is the result of the record number divided into the SQL buffer size (128k). I can't recall when the number read reached the 32k array limit but if the SQL buffer can't store them I'm betting it's more efficient to stay within the buffer limits. I've posted the code before under a similar thread. If you are interested in the code I'm sure it's in the archives. Rick
-----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Alan G. Campin Sent: Thursday, July 20, 2006 4:56 PM To: rpg400-l@xxxxxxxxxxxx Subject: Re: Controlling a fetch loopInteresting idea. Only problem is that 32766 row limitation. Iguessthat boils down to the "I know it will never exceed..." Murphyisim.Andit may never will for your application.Yea, I do not know why when IBM went to RPG IV, they put a max of 32766 on rows. If you could use real array you could go to 65763 but the IBM pre-complier is still RPG III based so who knows how long that will be. I am hoping that they are in the process of rewriting it. But, of course, the other issue is you only have 16MB total storage available but in practice, to need to read in more than 32766 records would seem unreal. That would say they is something wrong with the SQL. If one did have an issue like that, you could run a count and if over 32766, revert to a regular loop or read in 32766 and then read the next block although I am not sure about positioning back to the next record. -- This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/rpg400-l or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.