Curseurs de jeu de clés
Un curseur piloté par l’ensemble de clés se trouve entre un curseur statique et un curseur dynamique dans sa capacité à détecter les modifications. Comme un curseur statique, il ne détecte pas toujours les modifications apportées à l’appartenance et à l’ordre du jeu de résultats. Comme un curseur dynamique, il détecte les modifications apportées aux valeurs des lignes du jeu de résultats (sous réserve du niveau d’isolation de la transaction, tel que défini par l’attribut de connexion SQL_ATTR_TXN_ISOLATION).
Lorsqu’un curseur piloté par un jeu de clés est ouvert, il enregistre les clés de l’ensemble du jeu de résultats ; cela corrige l’appartenance et l’ordre apparents du jeu de résultats. Lorsque le curseur fait défiler le jeu de résultats, il utilise les clés de cet ensemble de clés pour récupérer les valeurs de données actuelles pour chaque ligne. Par exemple, supposons qu’un curseur piloté par l’ensemble de clés récupère une ligne et qu’une autre application met ensuite à jour cette ligne. Si le curseur refétise la ligne, les valeurs qu’il voit sont les nouvelles, car elle refétise la ligne à l’aide de sa clé. En raison de cela, les curseurs pilotés par l’ensemble de clés détectent toujours les modifications apportées par eux-mêmes et d’autres.
Lorsque le curseur tente de récupérer une ligne qui a été supprimée, cette ligne apparaît sous la forme d’un « trou » dans le jeu de résultats : la clé de la ligne existe dans l’ensemble de clés, mais la ligne n’existe plus dans le jeu de résultats. Si les valeurs de clés d’une ligne sont mises à jour, la ligne est considérée comme supprimée, puis insérée, de sorte que ces lignes apparaissent également sous forme de trous dans le jeu de résultats. Alors qu’un curseur piloté par les jeux de clés peut toujours détecter les lignes supprimées par d’autres, il peut éventuellement supprimer les clés des lignes qu’il supprime de l’ensemble de clés. Les curseurs pilotés par keyset qui effectuent cette opération ne peuvent pas détecter leurs propres suppressions. Si un curseur piloté par l’ensemble de clés particulier détecte ses propres suppressions est signalé via l’option SQL_STATIC_SENSITIVITY dans SQLGetInfo.
Les lignes insérées par d’autres ne sont jamais visibles par un curseur piloté par l’ensemble de clés, car aucune clé pour ces lignes n’existe dans l’ensemble de clés. Toutefois, un curseur piloté par l’ensemble de clés peut éventuellement ajouter les clés pour les lignes qu’il insère lui-même dans l’ensemble de clés. Les curseurs pilotés par keyset qui le font peuvent détecter leurs propres insertions. Si un curseur piloté par un jeu de clés particulier détecte ses propres insertions est signalé via l’option SQL_STATIC_SENSITIVITY dans SQLGetInfo.
Le tableau d’état de ligne spécifié par l’attribut d’instruction SQL_ATTR_ROW_STATUS_PTR peut contenir SQL_ROW_SUCCESS, SQL_ROW_SUCCESS_WITH_INFO ou SQL_ROW_ERROR pour n’importe quelle ligne. Elle retourne SQL_ROW_UPDATED, SQL_ROW_DELETED ou SQL_ROW_ADDED pour les lignes qu’elle détecte comme mises à jour, supprimées ou insérées.
Les curseurs pilotés par keyset sont généralement implémentés en créant une table temporaire qui contient les clés de chaque ligne du jeu de résultats. Étant donné que le curseur doit également déterminer si des lignes ont été mises à jour, cette table contient également généralement une colonne avec des informations de contrôle de version des lignes.
Pour faire défiler le jeu de résultats d’origine, le curseur piloté par l’ensemble de clés ouvre un curseur statique sur la table temporaire. Pour récupérer une ligne dans le jeu de résultats d’origine, le curseur récupère d’abord la clé appropriée à partir de la table temporaire, puis récupère les valeurs actuelles de la ligne. Si des curseurs de bloc sont utilisés, le curseur doit récupérer plusieurs clés et lignes.