Cursors cannot be re-opened after close #98
Labels
bug
Something isn't working
Comments
|
This patch should solve it, I hope to be able to issue a (pre?)release in the middle of next week containing also the improved |
mridoni
added a commit
that referenced
this issue
Aug 15, 2022
This is a maintenance pre-release for GixSQL. It fixes a few issues and adds two new databases drivers (Oracle and SQLite). The next "standard" release (presumably v1.0.18) will have feature parity for all database drivers. - Added new Oracle driver, based on ODPI - Added new SQLite driver - Solution for "PG: issue with prepared statements" (#99) - Solution for "PCursors cannot be re-opened after close" (#98) - Solution for "libgixpp: setStatus is called for errors without DBI parm passed - sets SQLERRM" (#94) - Solution for "error handling (especially for 07001)" (#92) - Solution for "show-stopper bug in pgsql_prepare" (#91) - Solution for "PREPARE does not work with VARLENGTH groups (ocesql compat)" (#79) - Partial solution for "PREPARE does not work with VARLENGTH groups (ocesql compat)" (#68) - Solution for "The PostgreSQL driver needs START TRANSACTION before using cursors" (#14) - Solution for "FR: support EXEC SQL VAR" (#21) - Fixed a bug in "problems with "codegen / logic issue for "GIXSQLCursorDeclareParams" (#88) - Fixed COMP-3 handling in drivers other than PostgreSQL - Rewrote the test suite (still MSTest-based) to dynamically generate a matrix of test to be run on the various platforms/database drivers
mridoni
added a commit
that referenced
this issue
Aug 23, 2022
- Added new Oracle driver, based on ODPI - Added new SQLite driver - All the drivers have been updated and now implement the complete set of supported features - Solution for "PG: issue with prepared statements" (#99) - Solution for "PCursors cannot be re-opened after close" (#98) - Solution for "libgixpp: setStatus is called for errors without DBI parm passed - sets SQLERRM" (#94) - Solution for "error handling (especially for 07001)" (#92) - Solution for "show-stopper bug in pgsql_prepare" (#91) - Solution for "PREPARE does not work with VARLENGTH groups (ocesql compat)" (#79) - Partial solution for "PREPARE does not work with VARLENGTH groups (ocesql compat)" (#68) - Solution for "The PostgreSQL driver needs START TRANSACTION before using cursors" (#14) - Solution for "FR: support EXEC SQL VAR" (#21) - Fixed a bug in "problems with "codegen / logic issue for "GIXSQLCursorDeclareParams" (#88) - Solution for "FR: allow mapping of "NoRecCode"' (#95) - added --no-rec-code parameter to gixpp - Tokens in the parser have been labeled to improve diagnostics (pulled PR #96 by @GitMensch) - Fixed COMP-3 handling in drivers other than PostgreSQL - Rewrote the test suite (still MSTest-based) to dynamically generate a matrix of test to be run on the various platforms/database drivers - Added options for parameter generation in gixpp (-a was removed) - Added new GIXSQL_FIXUP_PARAMS option for runtime, to automatically convert parameter format in prepared statments - "Native" cursors are now the default for the PostgreSQL driver - "Smart" cursor initialization is now the default for all cursors, including those declared in WORKING-STORAGE (-L was removed from gixpp), should fix #101 - Removed dynamic cursor emulation from the ODBC driver when using PostgreSQL
|
According to the release notes - solved. I suggest closing it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
currently when a cursor is closed, it is not just marked as such, but its declaration is removed. Since there is no
UNDECLARE CURSOR, at the time it seemed the logical thing to do, but in all evidence it is not, since it prevents one from re-opening the cursor after it has been closed.The solution might be just marking it as closed and destroying only the resources (if any) allocated when it is was opened, so leaving it ready for being re-opened.
Originally posted by @mridoni in #88 (comment)
The text was updated successfully, but these errors were encountered: