Closed lpillar closed 7 years ago
SQLFetch => done with row, moved to next row so can't retrieve any data from bindings -skip data-at-fetch -don't populate additional buffers, ignore any type exceptions -add dynamic columns to descriptor but don't retrieve
For SQLNextColumn with null => I don't want any more data-at-fetch. Skip to end of row but let me inspect bound values, maybe call GetData (depending on GD_Extensions) -skip data-at-fetch -if not set to SQL_TE_ERROR, treat as SQL_TE_CONTINUE -add dynamic columns to descriptor but don't retrieve
Updated 6.1.1 Usage for SQLNextColumn:
Calling SQLNextColumn with a null pointer for Col_or_Param_Num
populates any remaining bound columns, skipping any DATA_AT_FETCH
columns within the rowset. Dynamic columns are added to the descriptor as unbound columns and do not result in SQL_DATA_AVAILABLE
. Any length exceptions are treated as SQL_LE_CONTINUE
. If SQL_ATTR_TYPE_EXCEPTION_BEHAVIOR
is SQL_TE_ERROR
then an error is returned if any data values within the rowset are incompatible with their bound types, otherwise any type exceptions are treated as SQL_TE_CONTINUE
.
Calling SQLFetch or SQLFetchScroll continues to the next rowset, adding any dynamic columns to the descriptor as unbound columns but otherwise skipping any DATA_AT_FETCH
columns and ignoring type or length exceptions within the current rowset.
When calling SQLNextColumn with a null Col_or_Param_Num, should skipped dynamic columns be treated as though they were seen, and thus not treated as new dynamic columns in future fetches, or should they be treated as though they were not seen, and thus generate SQL_DATA_AVAILABLE for subsequent fetches?
Mike mentioned that we could change Fetch to fully skip all remaining Data-at-Fetch or Dynamic columns instead of generating a function sequence error, while calling SQLNextColumn with a null Col_or_Param_Num would treat any remaining columns as though they were seen and not bound. Unless anyone can think of a better solution, we should add this to the spec.