Hi Alan,

the statement look legit, but maybe it’s the code constellation around it. So I really would try to shorten the code as far as possible and try the program step by step.

But what makes me wonder a bit is, why do you need a sensitive dynamic scroll cursor, if all you do is a multi-row fetch and close it directly afterwards.

As I always think it’s ME and not the compiler, I always simply further and further until I find a problem, or I’m sure it’s an OS or compiler problem which I can report to IBM - the simplified program will then come handy for the error report.

Maybe you can cut down the source to 50-100
lines, confirm the problem still persists and send it - then I can try it with some example table on PUB400 or another machine.

HTH and kind regards,
Daniel

Von meinem iPhone gesendet

Am 16.06.2022 um 17:27 schrieb Alan Cassidy <cfuture@xxxxxxxxxxx>:

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

That's it. The program loads the subfile from the data-structure array MX and then processes each of them in a FOR-loop up to the number of RowsFetched.

On 6/16/2022 8:23 AM, Daniel Gross wrote:
Hi Alan,

we do this all the time - lingering the cursors open to fetch additional rows when the user is paging forward - and closing and re-opening the cursor when users are refreshing with F5 - so I dare to say, that this is not a (pre-)compiler issue, but something hidden in the code.

OK - maybe some missing PTF - on which release is it?

Is this all happening in one program? Sub-procedures? Service-Programs? Activation Groups?

Let’s make it simple and recite Linus Torwalds: Talk is cheap, show me the code!

Is it possible to prepare a shortened version of the program that does create the same „glitch“ and post the code?

Regards,
Daniel

Von meinem iPhone gesendet

Am 16.06.2022 um 13:52 schrieb Alan Cassidy<cfuture@xxxxxxxxxxx>:

It seems to me if you close a cursor it should clear out everything, or at least when you reopen it. I'm not ready to say this is a compiler glitch but I at least need a work-around. I can't tell the users to hit F5 twice to get the Refresh.

--Alan

On 6/12/2022 12:43 PM, Sam_L wrote:
Sounds like it's probably a bug in you code. In debug, check the fields that control what is selected by the cursor. Perhaps something is being reset from the subfile or other display file to program variable interaction.

Also be sure you are checking the SQL status after both opening and closing the cursor.

Sam

On 6/11/2022 3:13 PM, Alan Cassidy wrote:
Good day all,

I have a program that declares and opens a cursor. The fetch is Load-All into a DS array that I use to populate a subfile. When the program first runs, works fine, I'm getting data displayed in the subfile, apparently data that should be there.

Here is the sequence of events:

1. Declare and open cursor M1.

2. Fetch all selected records into a DS array. Data is returned to the array.

3. Close the cursor.

4. Populate the subfile from the DS array. I see data, looks good.

5. Press F5 to refresh the data. (The cursor is based on an SQL View that should return data that reflects changes to the underlying tables/files the View is based on.

6. Returns ZERO rows. No data. Diagnostic data says zero too. So the subfile is what I call empty.

7. F5 again. Repeat steps 1 thru 4 again, this time there is data again.

After that it's a cycle. Press F5, blank screen. F5 again, data. F5 again, blanks. F5 again, data!

I thought of doing a DYNAMIC SENSITIVE SCROLL CURSOR so the cursor itself could get updated dynamically from data changes, /and/ at the same time I can FETCH FIRST again and start over.

Except then I need to rerun the Declare and Open when they request to position to certain other places in the data, plus I want to implement something like this for another place in the program where the users can request a different ORDER BY.

Any idea why this is happening, and more important how to "fix it"?

To anybody who replies, THANK YOU!

--Alan
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email:RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:https://lists.midrange.com/mailman/listinfo/rpg400-l
or email:RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
athttps://archive.midrange.com/rpg400-l.

Please contactsupport@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link:https://amazon.midrange.com
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 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.