Re: SQL Cursor issues

How about creating a very short test program that demonstrates the problem? Open cursor, fetch cursor, close cursor, DSPLY sqlcode and wait for input from the DSPLY, then loop back and do it again. Takes all the F5 and subfiles logic out of the equation.

If you can do that, then I think you have a good basis to contact IBM.

Sam

On 6/16/2022 11:27 AM, Alan Cassidy wrote:

Here you are Daniel. The code itself.  (Good quote from Linus Torvalds). As you can see, it is based on an SQL View object. That is becaue the data is constantly changing throughout the day as they work on it. It's a Load-all Fetch, which will be just today's work....

To declare and open the cursor:

*         exec sql Declare M1 SENSITIVE DYNAMIC SCROLL CURSOR for
         SELECT * FROM TSTALANC.CS58V003
           WHERE :PASCCHCE = 2 AND
                 :PASCNAME IN (CSCAS, CSNTCAS, CS44CAS)
              OR :PASCCHCE = 3 AND
                 :PASCNAME IN (CSCAS, CSNTCAS, CS44CAS)
              OR :PASCCHCE IN (0,1) AND :@@USER = CSUSER AND
                 :SVKEY < MAINKEY
           ORDER BY CS15X3AD, CS15PUDT, CS15OT, CS15PRO ;
           //
         exec sql Open M1 ;*

Then the fetch which is set to do a multi-row fetch, and the 5000 will more than cover the numbers of rows for fetching well into the future (This is data for only one day's work). And if they ever need more than 5000 in a subfile, that's enough to work on all day, and they can always hit F5 to refresh to get more (by reopening the cursor and fetching again)

The fetch:

*         exec sql**
**           Fetch First from M1 for :RowsToFetch rows into :MX ;*

And after that fetch:

*exec sql Close M1; *