search

microsoft / ODBC-Specification

Microsoft ODBC Specification
Other
121 stars 40 forks source link

Error reporting in multi-row fetches #92

Closed matthew-wozniczka closed 7 years ago

matthew-wozniczka commented 7 years ago

In ODBC 3.8, from my reading of the spec ( https://docs.microsoft.com/en-us/sql/odbc/reference/syntax/sqlfetch-function Error Handling), the application can't (reliably) look at the bindings for any rows marked as SQL_ROW_ERROR. So, even if only 1 column in that row had an error, the application could not get the values for other columns.

Perhaps we could extend the idea for SQL_TYPE_EXCEPTION to cover any sort of error in retrieving a given cell, not just conversion errors. Then the driver would be obligated to set the length indicator for cells in error to some sentinel value, and the application could safely inspect the results for that row.

mikepizzo commented 7 years ago

Interesting idea. Currently we set DATA_UNAVAILABLE for columns that aren't included in the current row as well as type exceptions

We should define a different indicator, SQL_DATA_ERROR for type exceptions. Upon encountering an error populating a binding, the driver should set the indicator to SQL_DATA_ERROR and continue processing. A client working with a 4.0 driver should then be able to inspect columns for rows marked as SQL_ROW_ERROR.

mikepizzo commented 7 years ago

Actually, we should use the new SQL_TYPE_EXCEPTION indicator for type exceptions.

mikepizzo commented 7 years ago

Covered by 3.7.3.1 SQL_ATTR_TYPE_EXCEPTION_BEHAVIOR

SQL_TE_CONTINUE marks the type exception in the str_len_or_ind_ptr and continues.

This includes continuing in a multi-row case.

Does this cover the scenario? Do we need to clarify anything?