This is my personal preference too. There is only one fetch to maintain, and the program flow is totally unambiguous. Dennis McGrath
________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Thursday, June 11, 2009 4:56 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Cursor operation continues after end of data Randy: Marc is right. It is evaluating true because it is looking at the LAST command that's before your while loop. FWIW, I never use the "WHILE SQLCODE <> 100 THEN" structure because of that. I just don't trust to know what command it is evaluating. I always do this: DECLARE c1 CURSOR FOR SELECT ..... OPEN c1 WHILE 1 = 1 THEN FETCH c1 INTO vars.... IF SQLCODE = 100 THEN BREAK ENDIF ENDWHILE Karen I have a cursor operation that prints a report for a list of people. It is so enthusiastic that it continues to print after the end of data is reached. Unfortunately it duplicates the final report and seems to be in an endless loop which requires an inelegant exit from the program. When I traced the operation I can confirm that the value for SQLCODE changes so that it is no longer 100. That should interrupt the: WHILE SQLCODE <>100 THEN Thinking that I might not have been talking loud enough, I reminded the program again that 100 was reached with the following command, which was also ignored: IF SQLCODE = 100 THEN GOTO lfinish ENDIF ENDWHILE LABEL lfinish and so forth. Sometimes I figure out what is not working while I attempt to document it for someone else. Not this time... Can you suggest how I can help the operation to stop when it is complete. Best R:egards, Randy Peterson
