Sometimes procedure does not advance to next record

Panorama X Beta 10.2
1

I assume this question is impossible to answer in a helpful way. But maybe I will get lucky.
I have procedure that loops through the selected records. For each record, it generates a piece of text and adds it to a text file. BUT, for some reason, it repeats of a few of the records; it doesn’t advance to the next record. I used the following procedure to do the looping, and I added the zlog statements so I could see that it was advancing.

loop
call [my procedure that creates the text output for one record]
stoploopif info(“eof”)
zlog “going to next record”
downrecord
zlog "starting "+ID
while forever

The procedure loops through 144 records; for 140 of them it works correctly. For four records, the same four each time, it does not advance to the next record. It should be …152, …153, …154, etc.

But log shows this: you can see it did not move from 153 to 154. Three other records show the same issue. (I confirmed that there is only one record ending in 153.)

Circuit data/saveStandardTitleRec] starting 2023009153
[Circuit data/saveStandardTitleRec] going to next record
[Circuit data/saveStandardTitleRec] starting 2023009153
[Circuit data/saveStandardTitleRec] going to next record

I am at a loss after hours trying to solve this problem.

2

The fact that you have 144 iterations, which is between 4×32 and 5×32, suggests this is a version of the same bug you reported last March: every 32 iterations of a loop, one is repeated. Since then I have avoided this kind of loop in such situations.

3

Thanks Peter. You are correct.
I am working on a database that I converted from Pan6. This procedure was working to produce the correct output in Pan6, and it did not occur to me that the loop was a problem. And I usually avoid thinking that the problem is with PanX code, even though that does occur once in a while. The probability that I have made a mistake is much greater than the probability that PanX has a bug. I was focussed on the downrecord statment, and not on the loop itself and forgot the earlier issue.
Jim, what happened with this problem?

4

No, it’s a bug, and as Peter said, it’s a bug you have already reported!

Today I’ve revisited this bug and I’ve made some partial progress. You can get your code working by putting a disableabort statement above the loop, with an enableabort statement after the loop.

This is a somewhat new bug, it was introduced when Panorama gained the ability to stop a loop by pressing SHIFT-COMMAND-ESCAPE. Every 32 times thru the loop Panorama pauses to check for that key combination. Unfortunately, it turns out that in the process of doing that, it doesn’t correctly “un-pause”. I haven’t yet figured out how to make this happen correctly, but I have determined that using disableabort bypasses the problem (because if aborts are disabled it doesn’t pause to check for SHIFT-COMMAND-ESCAPE).

Note that this problem only occurs for loops that might be infinite. If Panorama knows for sure that the loop isn’t infinite, it won’t check for SHIFT-COMMAND-ESCAPE. So this problem doesn’t happen if you are using for or looparray.