Partage via


Curseurs ODBC

Une application extrait des données avec un curseur. Un curseur est différent d’un jeu de résultats : un jeu de résultats est l’ensemble de lignes qui correspondent à des critères de recherche particuliers, tandis qu’un curseur est le logiciel qui retourne ces lignes à l’application. Le curseur de nom , tel qu’il s’applique aux bases de données, provient probablement du curseur de clignotement sur un terminal d’ordinateur. Tout comme ce curseur indique la position actuelle à l’écran et où les mots tapés apparaissent ensuite, un curseur d’un jeu de résultats indique la position actuelle dans le jeu de résultats et la ligne qui sera retournée ensuite.

Le modèle de curseur dans ODBC est basé sur le modèle de curseur dans SQL incorporé. Une différence notable entre ces modèles est la façon dont les curseurs sont ouverts. Dans SQL incorporé, un curseur doit être explicitement déclaré et ouvert avant de pouvoir être utilisé. Dans ODBC, un curseur est implicitement ouvert lorsqu’une instruction qui crée un jeu de résultats est exécutée. Lorsque le curseur est ouvert, il est positionné avant la première ligne du jeu de résultats. Dans SQL incorporé et ODBC, un curseur doit être fermé une fois l’application terminée.

Différents curseurs ont des caractéristiques différentes. Le type de curseur le plus courant, appelé curseur vers l’avant uniquement, ne peut avancer que dans le jeu de résultats. Pour revenir à une ligne précédente, l’application doit fermer et rouvrir le curseur, puis lire les lignes du début du jeu de résultats jusqu’à atteindre la ligne requise. Les curseurs vers l’avant uniquement fournissent un mécanisme rapide pour effectuer un passage unique via un jeu de résultats.

Les curseurs vers l’avant uniquement sont moins utiles pour les applications basées sur l’écran, dans lesquelles l’utilisateur fait défiler vers l’arrière et vers l’avant les données. Ces applications peuvent utiliser un curseur vers l’avant uniquement en lisant le jeu de résultats une seule fois, en mettant en cache les données localement et en effectuant un défilement eux-mêmes. Toutefois, cela fonctionne correctement uniquement avec de petites quantités de données. Une meilleure solution consiste à utiliser un curseur défilant, qui fournit un accès aléatoire au jeu de résultats. Ces applications peuvent également augmenter les performances en récupérant plusieurs lignes de données à la fois, en utilisant ce qu’on appelle un curseur de bloc. Pour plus d’informations sur les curseurs de bloc, consultez Utilisation de curseurs de bloc.

Le curseur avant uniquement est le type de curseur par défaut dans ODBC et est abordé dans les sections suivantes. Pour plus d’informations sur les curseurs de bloc et les curseurs défilants, consultez Les curseurs de bloc et les curseurs pouvant faire défiler.

Important

La validation ou la restauration d’une transaction, soit en appelant explicitement SQLEndTran , soit en fonctionnant en mode de validation automatique, entraîne la fermeture de certaines sources de données de tous les curseurs sur toutes les instructions d’une connexion. Pour plus d’informations, consultez les attributs SQL_CURSOR_COMMIT_BEHAVIOR et SQL_CURSOR_ROLLBACK_BEHAVIOR dans la description de la fonction SQLGetInfo .