Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Important
Cette fonctionnalité sera supprimée dans une prochaine version de Windows. Évitez d’utiliser cette fonctionnalité dans le nouveau travail de développement et prévoyez de modifier les applications qui utilisent actuellement cette fonctionnalité. Microsoft recommande d’utiliser la fonctionnalité de curseur du pilote.
Pour supporter les instructions de mise à jour et de suppression positionnées, la bibliothèque de curseurs construit une instruction recherchée UPDATE ou DELETE à partir de l’instruction positionnée. Pour supporter les appels à SQLGetData dans un bloc de données, la bibliothèque de curseurs construit une instruction SELECT recherchée pour créer un ensemble de résultats contenant la ligne de données courante. Dans chacune de ces instructions, la clause WHERE énumère les valeurs stockées dans le cache pour chaque colonne liée qui retourne SQL_PRED_SEARCHABLE ou SQL_PRED_BASIC pour l’identifiant de champ SQL_DESC_SEARCHABLE dans SQLColAttribute.
Caution
La clause WHERE construite par la bibliothèque de curseurs pour identifier la ligne courante peut ne pas identifier de lignes, identifier une ligne différente, ou en identifier plusieurs.
Si une instruction mise à jour ou suppression positionnée affecte plus d’une ligne, la bibliothèque de curseurs met à jour le tableau d’état des lignes uniquement pour la ligne sur laquelle le curseur est positionné et retourne SQL_SUCCESS_WITH_INFO et SQLSTATE 01001 (conflit d’opération de curseur). Si l’instruction n’identifie aucune ligne, la bibliothèque de curseurs ne met pas à jour le tableau d’état des lignes et renvoie SQL_SUCCESS_WITH_INFO et SQLSTATE 01001 (conflit d’opération de curseur). Une application peut appeler SQLRowCount pour déterminer le nombre de lignes mises à jour ou supprimées.
Si la clause SELECT utilisée pour positionner le curseur d’un appel à SQLGetData identifie plus d’une ligne, SQLGetData n’est pas garanti de renvoyer les données correctes. S’il n’identifie aucune ligne, SQLGetData renvoie SQL_NO_DATA.
Si une application respecte les directives suivantes, la clause WHERE construite par la bibliothèque de curseurs doit identifier de manière unique la ligne courante, sauf lorsque cela est impossible, par exemple lorsque la source de données contient des lignes en double.
Liez des colonnes qui identifient de manière unique la ligne. Si les colonnes liées n’identifient pas de manière unique la ligne, la clause WHERE construite par la bibliothèque de curseurs pourrait en identifier plusieurs. Dans une instruction mise à jour ou suppression positionnée, une telle clause peut entraîner la mise à jour ou la suppression de plus d’une ligne. Lors d’un appel à SQLGetData, une telle clause peut faire renvoyer les données du pilote pour la mauvaise ligne. Lier toutes les colonnes d’une clé unique garantit que chaque ligne est identifiée de manière unique.
Allouez des tampons de données suffisamment grands pour qu’aucune troncature n’ait lieu. Le cache de la bibliothèque de curseurs est une copie des valeurs des tampons de rowset liées à l’ensemble de résultats avec SQLBindCol. Si les données sont tronquées lorsqu’elles sont placées dans ces tampons, elles seront également tronquées dans le cache. Une clause WHERE construite à partir de valeurs tronquées peut ne pas identifier correctement la ligne sous-jacente dans la source de données.
Spécifier des tampons non à longueur nulle pour les données binaires C. La bibliothèque de curseurs alloue des tampons de longueur dans son cache uniquement si l’argument StrLen_or_IndPtr dans SQLBindCol est non nul. Lorsque l’argument TargetType est SQL_C_BINARY, la bibliothèque de curseurs exige la longueur des données binaires pour construire une clause WHERE à partir des données. S’il n’y a pas de tampon de longueur pour une colonne SQL_C_BINARY et que l’application appelle SQLGetData ou tente d’exécuter une instruction de mise à jour ou de suppression positionnée, la bibliothèque de curseurs retourne SQL_ERROR et SQLSTATE SL014 (une requête positionnée a été émise et tous les champs de comptage de colonnes n’ont pas été tamponnés).
Spécifiez des tampons non à longueur nulle pour les colonnes nullables. La bibliothèque de curseurs alloue des tampons de longueur dans son cache uniquement si l’argument StrLen_or_IndPtr dans SQLBindCol est non nul. Comme SQL_NULL_DATA est stocké dans le tampon de longueur, la bibliothèque de curseurs suppose que toute colonne pour laquelle aucun tampon de longueur n’est spécifié n’est pas nulle. Si aucune colonne de longueur n’est spécifiée pour une colonne annulable, la bibliothèque de curseurs construit une clause WHERE qui utilise la valeur de données de la colonne. Cette clause n’identifiera pas correctement la ligne.