Fix Version: Jaybird 5 [ 10871 ]

description: In JDBC571 we added some stopgap measures for CURSOR_OPEN state affecting reuse. We need to investigate if there is a better, more general solution possible. Part of the problem is that the driver relies (relied) on result set creation to properly closer the statement cursor, while some code paths don't create a result set (or fail to create on, as addressed in JDBC571).

For example another codepath that causes this problem (which is corrected by the stopgap measure `ensureClosedCursor`) is executing a select with `Statement.execute(..)`, but never actually retrieving the result set with `getResultSet()`. Before the stopgap measure, this would leave the statement in CURSOR_OPEN state, disallowing reuse.

=>

In JDBC571 we added some stopgap measures for CURSOR_OPEN state affecting reuse. We need to investigate if there is a better, more general solution possible. Part of the problem is that the driver relies (relied) on result set creation to properly closer the statement cursor, while some code paths don't create a result set (or fail to create one, as addressed in JDBC571).

For example another codepath that causes this problem (which is corrected by the stopgap measure `ensureClosedCursor`) is executing a select with `Statement.execute(..)`, but never actually retrieving the result set with `getResultSet()`. Before the stopgap measure, this would leave the statement in CURSOR_OPEN state, disallowing reuse.

Link: This issue is related to JDBC531 [ JDBC531 ]

Link: This issue is related to JDBC571 [ JDBC571 ]

description: In JDBC571 we added some stopgap measures for CURSOR_OPEN state affecting reuse. We need to investigate if there is a better, more general solution possible. Part of the problem is that the driver relies (relied) on result set creation to properly closer the statement cursor, while some code paths don't create a result set (or fail to create one, as addressed in JDBC571).

For example another codepath that causes this problem (which is corrected by the stopgap measure `ensureClosedCursor`) is executing a select with `Statement.execute(..)`, but never actually retrieving the result set with `getResultSet()`. Before the stopgap measure, this would leave the statement in CURSOR_OPEN state, disallowing reuse.

=>

In JDBC571 we added some stopgap measures for CURSOR_OPEN state affecting reuse. We need to investigate if there is a better, more general solution possible. Part of the problem is that the driver relies (relied) on result set creation to properly close the statement cursor, while some code paths don't create a result set (or fail to create one, as addressed in JDBC571).

For example another codepath that causes this problem (which is corrected by the stopgap measure `ensureClosedCursor`) is executing a select with `Statement.execute(..)`, but never actually retrieving the result set with `getResultSet()`. Before the stopgap measure, this would leave the statement in CURSOR_OPEN state, disallowing reuse.