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
I was looking into a test which was failing in iODBC (3.52.8, .9, and .15), but not in any version of unixODBC.
The issue was that the call to SQLDriverConnectW was returning SQL_SUCCESS_WITH_INFO, but when the application tried to retrieve diagnostics using SQLGetDiagRecordW, there were none (i.e. it returned SQL_NO_DATA even for RecNumber == 1). Looking into the driver logs, the driver was posting a warning during the connect.
I was looking at the source, and I believe the issue (haven't had the time to actually debug it thoroughly) is that after calling into the driver's implementation of SQLDriverConnect(W), iODBC is calling _iodbcdm_dbcdelayset, which ends up calling SQLGetInfo(W) in the driver (& possibly also other functions if the application set any connection attributes before the SQLDriverConnect(W) call), which ends up resetting the diagnostics exposed by the driver (since the ODBC model is that the exposed diagnostics are always for the preceding ODBC API call on the handle), and there's no logic in iODBC to preserve the diagnostics exposed by the driver directly after the SQLDriverConnect(W) call, so they are simply lost.
The text was updated successfully, but these errors were encountered:
I was looking into a test which was failing in iODBC (3.52.8, .9, and .15), but not in any version of unixODBC.
The issue was that the call to
SQLDriverConnectW
was returningSQL_SUCCESS_WITH_INFO
, but when the application tried to retrieve diagnostics usingSQLGetDiagRecordW
, there were none (i.e. it returnedSQL_NO_DATA
even forRecNumber
== 1). Looking into the driver logs, the driver was posting a warning during the connect.I was looking at the source, and I believe the issue (haven't had the time to actually debug it thoroughly) is that after calling into the driver's implementation of
SQLDriverConnect(W)
, iODBC is calling_iodbcdm_dbcdelayset
, which ends up callingSQLGetInfo(W)
in the driver (& possibly also other functions if the application set any connection attributes before theSQLDriverConnect(W)
call), which ends up resetting the diagnostics exposed by the driver (since the ODBC model is that the exposed diagnostics are always for the preceding ODBC API call on the handle), and there's no logic in iODBC to preserve the diagnostics exposed by the driver directly after theSQLDriverConnect(W)
call, so they are simply lost.The text was updated successfully, but these errors were encountered: