Calling SQLCancel cancels the fetch operation and closes the cursor.
[after SQLFetch/SQLFetchScroll return SQL_DATA_AVAILABLE] (and presumably the same for SQL_METADATA_CHANGED/SQL_MORE_DATA).
Because SQLCancel does both synchronous and asynchronous cancellation, this behavior can cause a race condition: an application attempting an asynchronous cancellation of a call to SQLFetch/SQLFetchScroll may unintentionally end up doing a synchronous cancellation if that call happens to return 'too early', and thus unintentionally close the cursor.
Instead, perhaps we could allow SQLCloseCursor/SQLFreeStmt(SQL_CLOSE) to fulfill that purpose?
Section 3.6 (Getting Data during Fetch) says that
[after
SQLFetch
/SQLFetchScroll
returnSQL_DATA_AVAILABLE
] (and presumably the same forSQL_METADATA_CHANGED
/SQL_MORE_DATA
).Because
SQLCancel
does both synchronous and asynchronous cancellation, this behavior can cause a race condition: an application attempting an asynchronous cancellation of a call toSQLFetch
/SQLFetchScroll
may unintentionally end up doing a synchronous cancellation if that call happens to return 'too early', and thus unintentionally close the cursor.Instead, perhaps we could allow
SQLCloseCursor
/SQLFreeStmt(SQL_CLOSE)
to fulfill that purpose?