Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DECLARE in PROCEDURE DIVISION is executed multiple times #101

Closed
GitMensch opened this issue Aug 17, 2022 · 2 comments
Closed

DECLARE in PROCEDURE DIVISION is executed multiple times #101

GitMensch opened this issue Aug 17, 2022 · 2 comments

Comments

@GitMensch
Copy link
Contributor

GitMensch commented Aug 17, 2022

scenario: io program (called often) which does

  • check if cursor is open - in this case close it
  • always do EXEC SQL DECLARE CURSOR CCCC
  • if sqlcode zero: do EXEC SQL OPEN CCCC
  • 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.

@GitMensch 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
@GitMensch
Copy link
Contributor Author

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).

@mridoni
Copy link
Owner

mridoni commented Aug 19, 2022

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants