Curseurs avec défilement
Dans les applications modernes basées sur l’écran, l’utilisateur fait défiler vers l’arrière et vers l’avant les données. Pour ces applications, le retour à une ligne extraite précédemment est un problème. Une possibilité consiste à fermer et rouvrir le curseur, puis à extraire des lignes jusqu’à ce que le curseur atteigne la ligne requise. Une autre possibilité consiste à lire le jeu de résultats, à le mettre en cache localement et à implémenter le défilement dans l’application. Les deux possibilités fonctionnent bien uniquement avec de petits jeux de résultats, et cette dernière possibilité est difficile à implémenter. Une meilleure solution consiste à utiliser un curseur défilant, qui peut se déplacer vers l’arrière et l’avant dans le jeu de résultats.
Un curseur à défilement est couramment utilisé dans les applications modernes basées sur l’écran dans lesquelles l’utilisateur fait défiler les données. Toutefois, les applications doivent utiliser des curseurs à défilement uniquement lorsque les curseurs vers l’avant uniquement ne feront pas le travail, car les curseurs à défilement sont généralement plus coûteux que les curseurs vers l’avant uniquement.
La possibilité de se déplacer vers l’arrière soulève une question non applicable aux curseurs vers l’avant uniquement : un curseur à défilement doit-il détecter les modifications apportées aux lignes précédemment extraites ? Autrement dit, doit-il détecter les lignes mises à jour, supprimées et nouvellement insérées ?
Cette question se pose parce que la définition d’un jeu de résultats - l’ensemble de lignes qui correspondent à certains critères - n’indique pas quand les lignes sont case activée ed pour voir si elles correspondent à ces critères, ni indiquent si les lignes doivent contenir les mêmes données chaque fois qu’elles sont extraites. L’ancienne omission permet aux curseurs à défilement de détecter si des lignes ont été insérées ou supprimées, tandis que ces dernières permettent de détecter les données mises à jour.
La possibilité de détecter les modifications est parfois utile, parfois pas. Par exemple, une application comptable a besoin d’un curseur qui ignore toutes les modifications ; les livres d’équilibrage sont impossibles si le curseur affiche les dernières modifications. En revanche, un système de réservation de compagnies aériennes a besoin d’un curseur qui affiche les dernières modifications apportées aux données ; sans ce curseur, il doit continuellement réexécuter la base de données pour afficher la disponibilité de vol la plus récente.
Pour couvrir les besoins de différentes applications, ODBC définit quatre types de curseurs défilants. Ces curseurs varient à la fois en dépenses et en leur capacité à détecter les modifications apportées au jeu de résultats. Notez que si un curseur défilant peut détecter les modifications apportées aux lignes, il ne peut les détecter que lorsqu’il tente de réacheminer ces lignes ; il n’existe aucun moyen pour la source de données d’informer le curseur des modifications apportées aux lignes actuellement extraites. Notez également que la visibilité des modifications est également contrôlée par le niveau d’isolation des transactions ; pour plus d’informations, consultez Isolation des transactions.
Cette section contient les rubriques suivantes :