search

microsoft / ODBC-Specification

Microsoft ODBC Specification
Other
121 stars 40 forks source link

Behaviour of deferred buffers in interrupted fetches #101

Closed matthew-wozniczka closed 7 years ago

matthew-wozniczka commented 7 years ago

When a deferred buffer is used during a fetch which is interrupted, when is the driver allowed to write into it?

During any call to SQLFetch/SQLFetchScroll/SQLNextColumn? Only during the 'last' call to those functions (the one that completes the fetch)? Any time between the call to the initiating SQLFetch/SQLFetchScroll and the final SQLNextColumn which completes the fetch (i.e. from a background thread)? (this would give the most flexibility to the driver)

Can any deferred fields in the ARD be changed (via SQLSetDescField/SQLSetStmtAttr) during an interrupted fetch? (I would say no)

The spec already has SQL_ATTR_ROWS_FETCHED_PTR being populated during SQLNextColumn, but I don't think it mentions the others.

matthew-wozniczka commented 7 years ago

Does the spec say anything about the analogous situation already existing in ODBC 3.8 when an execution is interrupted with SQL_NEED_DATA?

mikepizzo commented 7 years ago

The buffers are populated at any time prior to SQLFetch/SQLFetchScroll/SQLNextColumn returning SQL_SUCCESS or SQL_SUCCESS_WITH_INFO.

We allow changing only the descriptor record for the current column during a fetch (which, based on issue #118, doesn't take affect until the next call to SQLFetch/SQLFetchScroll)

mikepizzo commented 7 years ago

The following statement in step 7 of Getting Data During Fetch is meant to clarify that the application can't assume deferred buffers are populated until the fetch concludes:

The application must not assume any bindings have been populated until SQLNextColumn returns SQL_SUCCESS or SQL_SUCCESS_WITH_INFO.