Partager via

Effet des transactions sur les curseurs et les instructions préparées

  • Article

La validation ou la restauration d’une transaction a l’un des effets suivants sur les curseurs et les plans d’accès :

  • Tous les curseurs sont fermés et les plans d’accès pour les instructions préparées sur cette connexion sont supprimés, ou

  • Tous les curseurs sont fermés et les plans d’accès pour les instructions préparées sur cette connexion restent intacts, ou

  • Tous les curseurs restent ouverts et les plans d’accès pour les instructions préparées sur cette connexion restent intacts.

Par exemple, supposons qu’une source de données présente le premier comportement de cette liste, le plus restrictif de ces comportements. Supposons maintenant qu’une application effectue les opérations suivantes :

  1. Définit le mode de validation sur validation manuelle.

  2. Crée un jeu de résultats de commandes sur l’instruction 1.

  3. Crée un jeu de résultats des lignes d’une commande client sur l’instruction 2, lorsque l’utilisateur met en surbrillance cette commande.

  4. Appelle SQLExecute pour exécuter une instruction de mise à jour positionnée qui a été préparée sur l’instruction 3, lorsque l’utilisateur met à jour une ligne.

  5. Appelle SQLEndTran pour valider l’instruction de mise à jour positionnée.

En raison du comportement de la source de données, l’appel à SQLEndTran à l’étape 5 l’entraîne à fermer les curseurs sur les instructions 1 et 2 et à supprimer le plan d’accès sur toutes les instructions. L’application doit réexécuter les instructions 1 et 2 pour recréer les jeux de résultats et reprepre l’instruction sur l’instruction 3.

En mode de validation automatique, les fonctions autres que les transactions de validation SQLEndTran :

  • SQLExecute ou SQLExecDirect Dans l’exemple précédent, l’appel à SQLExecute à l’étape 4 valide une transaction. Cela entraîne la fermeture des curseurs sur les instructions 1 et 2 et la suppression du plan d’accès sur toutes les instructions de cette connexion.

  • SQLBulkOperations ou SQLSetPos Dans l’exemple précédent, supposons qu’à l’étape 4, l’application appelle SQLSetPos avec l’option SQL_UPDATE sur l’instruction 2, au lieu d’exécuter une instruction de mise à jour positionnée sur l’instruction 3. Cela valide une transaction et provoque la fermeture des curseurs sur les instructions 1 et 2, et dés carte tous les plans d’accès sur cette connexion.

  • SQLCloseCursor Dans l’exemple précédent, supposons que lorsque l’utilisateur met en surbrillance une commande différente, l’application appelle SQLCloseCursor sur l’instruction 2 avant de créer un résultat des lignes pour la nouvelle commande client. L’appel à SQLCloseCursor valide l’instruction SELECT qui a créé le jeu de résultats de lignes et provoque la fermeture du curseur sur l’instruction 1, puis dis carte tous les plans d’accès sur cette connexion.

Les applications, en particulier les applications basées sur l’écran dans lesquelles l’utilisateur défile autour du jeu de résultats et met à jour ou supprime des lignes, doivent faire attention à coder autour de ce comportement.

Pour déterminer le comportement d’une source de données lorsqu’une transaction est validée ou restaurée, une application appelle SQLGetInfo avec les options SQL_CURSOR_COMMIT_BEHAVIOR et SQL_CURSOR_ROLLBACK_BEHAVIOR.