Thanks Mark. It's nice to know we're not crazy (at least in this matter). Thank you to all who responded. I/we appreciate the advice, especially the use of COUNT. It's amazing how easily tunnel-vision sets in and prohibits the consideration of something like COUNT when that is exactly what information we seek.
Jef -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MAJ Programming Sent: Saturday, 15 November 2008 1:23 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] SELECT-READNEXT That's odd I don't know all of the settings within U2 vs other MV platforms but one thing that was tricky for me straddling both is the concept that items from one active list remain despite a conclusion of the use of that list. Case in point is a SSELECT statement feeding IDS to a Data/Basic report program to the screen and the user types "Q" before all the IDS are consumed. I learned CLEARSELECT does what its name implies. This may also prevent any remaining IDS from an incomplete readnext cycle from being the preliminary IDS for the next SELECT statement. One workaround that I've incorporated within U2 and other platforms is my GET.IDS(TCL, IDS) subroutine. There, the sub retrieves ALL of the IDS (attributingly), thus consuming the active list that the TCL statement created (SSELECT, QSELECT, GET-LIST etc). Also, my sub GET.IDS can have any flavor differences between cycling through readnexts concluded once instead of for every use. I've been flamed that this is not good for massive amounts of processing as IDS would grow large.Agreed, but for many, many TCL statements returning a handful of IDS, it's great as the entire READNEXT construct is exercised. Also for any newbies watching. Do not put DCOUNT as the second value in a FOR...NEXT Loop. Assign it once prior to the FOR statement and the loop will be faster. MAX=DCOUNT(WORK.ITEM.REC<17>,VM) FOR I=1 TO MAX My 2 cents Mark Johnson ----- Original Message ----- From: "Jef Lee" <[EMAIL PROTECTED]> To: <u2-users@listserver.u2ug.org> Sent: Friday, November 14, 2008 2:39 AM Subject: [U2] SELECT-READNEXT That's odd > One of our programmers wrote this snippet: > > FOR YY=1 TO DCOUNT(WORK.ITEM.REC<17>,VM) > LISTNUMBER='' > SQLCOMMAND='' > UNISTATEMENT='SELECT BPM.WORKITEMS WITH A1="':WORK.ITEM.REC<1>:'" AND > WITH A2="':WORK.ITEM.REC<2>:'" AND WITH A17="':WORK.ITEM.REC<17,YY>:'" AND > WITH A24#"C" AND WITH A24#"R" AND WITH A24#"F"' > *MY.REC<1>=UNISTATEMENT > CALL SR.EXECUTESQL(LISTNUMBER,UNISTATEMENT,SQLCOMMAND) > READNEXT DEPENDANT.ID ELSE > * NO ACTIVE ITEMS LEFT I NEED TO UPDATE THE STATUS OF THE > DEPENDANT TASK > CALL > SR.READSQL('BPM.WORKITEMS',DEP.TASK.REC,WORK.ITEM.REC<17,YY>,'') > DEP.TASK.REC<24>='A' > DEP.TASK.REC<8>=DATE() > DEP.TASK.REC<9>=TIME() > CALL > SR.WRITESQL('BPM.WORKITEMS',DEP.TASK.REC,WORK.ITEM.REC<17,YY>) > END > NEXT YY > > The FOR loop has 2 values to iterate, so it does 2 loops. The function > SR.EXECUTESQL()does the SELECT call. > Loop 1 returns 2 keys found. > Loop 2 returns 0 keys found. > What's odd is that the select list is empty on loop iteration 2 and the > READNEXT is populated the ID with the second key from the first iteration. > > I looked in the help PDFs and all I found was a reference to a corrected error > relating to memory not being released if the READNEXT did not exhaust the > SELECT list. > > Any thoughts? > > We have since changed our strategy to check the count returned instead. But it > would be nice to know that others have encountered this as well. > > Jeffrey Lee > Senior Analyst/Programmer > > IT Vision Australia Pty Ltd (ABN: 34 309 336 904) > PO Box 881, Canning Bridge WA 6153 > Level 3, Kirin Centre, 15 Ogilvie Road, Applecross, WA, 6153 > P: (08) 9315 7000 F: (08) 9315 7088 > W: http://www.itvision.com.au > ___________________________________________________________ > > NOTICE : This e-mail and any attachments are intended for the addressee(s) > only and may > contain confidential or privileged material. Any unauthorised review, use, > alteration, > disclosure or distribution of this e-mail (including any attachments) by an > unintended recipient > is prohibited. If you are not the intended recipient please contact the sender > as soon as > possible by return e-mail and then delete both messages. > ___________________________________________________________ > ------- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
