Closed GitMensch closed 2 years ago
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 inDATA 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.