You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
if sqlcode zero: set internal cursor marker to "open" do EXEC SQL FETCH CCCC
Using ocesql this code runs (and I think it did with 1.0.17, too), using 1.0.18dev2 it doesn't as the DECLARE CURSOR is always executed and returns with sqlcode -110 DBERR_CURSOR_EXISTS.
I'm not 100% sure that this should work, but I think so. Can you please recheck?
If this is the case it would be best to apply the ESQL CURSOR INIT FLAGS logic used for cursors declared in DATA DIVISION also to cursors declared in PROCEDURE DIVISION.
If it isn't I'll try to get the code (some hundreds of programs) adjusted to either ignore -110 at this place or to additional handle the case "cursor declared once - so skip it" in the code.
The text was updated successfully, but these errors were encountered:
GitMensch
changed the title
DECLARE in PROCEDURE DIVISION is executed multiple times, should it?
DECLARE in PROCEDURE DIVISION is executed multiple times
Aug 17, 2022
Rechecked with ProCOB: Oracle does never generate the DECLARE in the PROCEDURE DIVISION where it was defined - but always on the same place (it actually references it on each OPEN CURSOR and seems to internally handle the "only declare once" part).
I therefore think that the ESQL CURSOR INIT FLAGS logic should be applied in every case (and to reduce the test matrix I'd suggest to drop gixsql -L option, too).
I therefore think that the ESQL CURSOR INIT FLAGS logic should be applied in every case (and to reduce the test matrix I'd suggest to drop gixsql -L option, too).
Implemented in the internal repository, no regressions detected, will be in v1.0.18 (-L was removed to, since it is no longer needed).
scenario: io program (called often) which does
EXEC SQL DECLARE CURSOR CCCC
EXEC SQL OPEN CCCC
EXEC SQL FETCH CCCC
Using ocesql this code runs (and I think it did with 1.0.17, too), using 1.0.18dev2 it doesn't as the
DECLARE CURSOR
is always executed and returns with sqlcode -110 DBERR_CURSOR_EXISTS.I'm not 100% sure that this should work, but I think so. Can you please recheck?If this is the case it would be best to apply the ESQL CURSOR INIT FLAGS logic used for cursors declared in
DATA DIVISION
also to cursors declared inPROCEDURE DIVISION
.If it isn't I'll try to get the code (some hundreds of programs) adjusted to either ignore -110 at this place or to additional handle the case "cursor declared once - so skip it" in the code.The text was updated successfully, but these errors were encountered: