Bloquer les curseurs, les curseurs défilants et la compatibilité descendante
L’existence des deux SQLFetchScroll et SQLExtendedFetch représente la première division claire dans ODBC entre l’interface de programmation d’application (API), qui est l’ensemble des fonctions que les appels d’application et l’interface de fournisseur de services (SPI), qui est l’ensemble de fonctions implémentées par le pilote. Ce fractionnement est nécessaire pour que ODBC 3.x, qui utilise SQLFetchScroll, soit aligné sur les normes et soit également compatible avec ODBC 2.x, qui utilise SQLExtendedFetch.
L’API ODBC 3.x, qui est l’ensemble de fonctions que l’application appelle, inclut sqlFetchScroll et les attributs d’instruction associés. ODBC SPI, qui est l’ensemble de fonctions implémentées par le pilote, inclut SQLFetchScroll, SQLExtendedFetchet les attributs d’instruction associés. Étant donné que ODBC n’applique pas formellement ce fractionnement entre l’API et le SPI, il est possible que les applications ODBC 3.x appellent SQLExtendedFetch et les attributs d’instruction associés. Toutefois, il n’existe aucune raison pour l’application ODBC 3.x d’effectuer cette opération. Pour plus d’informations sur les API et les SPIs, consultez l’introduction à architecture ODBC.
Pour plus d’informations sur les fonctions et attributs d’instruction qu’une application ODBC 3.x doit utiliser avec des curseurs de bloc et de défilement, consultez Curseurs de bloc, curseurs à défilement et compatibilité descendante pour les applications ODBC 3.x.
Cette section contient les rubriques suivantes.