Re: SQL Cursor issues

[Sam_L <lennon_s_j@xxxxxxxxxxx>]

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; *