Block Cursors, Scrollable Cursors, and Backward Compatibility

The existence of both SQLFetchScroll and SQLExtendedFetch represents the first clear split in ODBC between the Application Programming Interface (API), which is the set of functions the application calls, and the Service Provider Interface (SPI), which is the set of functions the driver implements. This split is required to balance the requirement in ODBC 3.0 to align with the standards, which uses SQLFetchScroll, and be compatible with ODBC 2.x, which uses SQLExtendedFetch.

The ODBC 3.0 API, which is the set of functions the application calls, includes SQLFetchScroll and related statement attributes. The ODBC 3.0 SPI, which is the set of functions the driver implements, includes SQLFetchScroll, SQLExtendedFetch, and related statement attributes. Note that because ODBC does not formally enforce this split between the API and the SPI, it is possible for ODBC 3.0 applications to call SQLExtendedFetch and related statement attributes. However, there is no reason for ODBC 3.0 application to do this. For more information about APIs and SPIs, see the introduction to Chapter 3, “ODBC Architecture.”

For information about what functions and statement attributes an ODBC 3.0 application should use with block and scrollable cursors, see “Block Cursors, Scrollable Cursors, and Backward Compatibility for ODBC 3.0 Applications” in Chapter 17, “Programming Considerations.”