You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix#1599: Remove SQLCancel from core_sqlsrv_next_result for user-facing APIs
When SQLMoreResults returns SQL_ERROR for a mid-batch statement failure
(e.g. divide-by-zero with XACT_ABORT OFF), the ODBC spec says it should
return SQL_SUCCESS_WITH_INFO when the batch is not aborted and the failed
statement is not the last one. The Microsoft ODBC driver incorrectly
returns SQL_ERROR, but the statement handle remains valid. The old code
called SQLCancel() in the catch block, which aborted the entire remaining
batch, making subsequent result sets unreachable.
This change adds a throw_on_errors parameter (default true) to
core_sqlsrv_next_result:
- throw_on_errors=true (default): used by internal flush loops
(closeCursor, re-execute, param binding). Uses the throwing
core::SQLMoreResults wrapper and calls SQLCancel in the catch block.
Same behavior as before.
- throw_on_errors=false: used only by sqlsrv_next_result() and
PDO::nextRowset(). Calls SQLMoreResults directly, reports the error
through the normal error handler, clears any pending PDO exception,
and falls through to new_result_set(). The batch remains navigable.
SQLCancel is NOT called in the catch block for this path.
Tests cover both extensions (ERRMODE_WARNING and ERRMODE_EXCEPTION for
PDO), re-execute after a batch error (flush loop), and error visibility
via sqlsrv_errors() / errorInfo().
Fixes#1599
// this is a list of implicit datatype conversion that SQL Server allows (https://docs.microsoft.com/en-us/sql/t-sql/data-types/data-type-conversion-database-engine)
0 commit comments