Partager via

Construction d’instructions de recherche

  • Article

Important

Cette fonctionnalité sera supprimée dans une version future 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 prendre en charge les instructions de mise à jour et de suppression positionnées, la bibliothèque de curseurs construit une instruction UPDATE ou DELETE recherchée à partir de l’instruction positionnée. Pour prendre en charge les appels à SQLGetData dans un bloc de données, la bibliothèque de curseurs construit une instruction SELECT recherchée pour créer un jeu de résultats contenant la ligne de données actuelle. 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’identificateur de champ SQL_DESC_SEARCHABLE dans SQLColAttribute.

Attention

La clause WHERE construite par la bibliothèque de curseurs pour identifier la ligne actuelle peut ne pas identifier les lignes, identifier une ligne différente ou identifier plusieurs lignes.

Si une instruction de mise à jour ou de suppression positionnée affecte plusieurs lignes, la bibliothèque de curseurs met à jour le tableau d’état de ligne 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 de ligne et retourne 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 qui ont été mises à jour ou supprimées.

Si la clause SELECT utilisée pour positionner le curseur d’un appel à SQLGetData identifie plusieurs lignes, IL n’est pas garanti que SQLGetData retourne les données correctes. S’il n’identifie aucune ligne, SQLGetData retourne SQL_NO_DATA.

Si une application est conforme aux instructions suivantes, la clause WHERE construite par la bibliothèque de curseurs doit identifier de manière unique la ligne active, sauf lorsque cela est impossible, par exemple lorsque la source de données contient des lignes en double.

  • Lier les colonnes qui identifient la ligne de manière unique. Si les colonnes liées n’identifient pas la ligne de manière unique, la clause WHERE construite par la bibliothèque de curseurs peut identifier plusieurs lignes. Dans une instruction de mise à jour ou de suppression positionnée, une telle clause peut entraîner la mise à jour ou la suppression de plusieurs lignes. Dans un appel à SQLGetData, une telle clause peut amener le pilote à retourner des données pour la ligne incorrecte. La liaison de toutes les colonnes d’une clé unique garantit que chaque ligne est identifiée de manière unique.

  • Allouez des mémoires tampons de données suffisamment grandes pour qu’aucune troncation ne se produise. Le cache de la bibliothèque de curseurs est une copie des valeurs dans les mémoires tampons d’ensemble de lignes liées au jeu de résultats avec SQLBindCol. Si les données sont tronquées lorsqu’elles sont placées dans ces mémoires tampons, elles sont é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écifiez des mémoires tampons de longueur non null pour les données C binaires. La bibliothèque de curseurs alloue des mémoires tampons de longueur dans son cache uniquement si l’argument StrLen_or_IndPtr dans SQLBindCol n’est pas null. Lorsque l’argument TargetType est SQL_C_BINARY, la bibliothèque de curseurs nécessite la longueur des données binaires pour construire une clause WHERE à partir des données. S’il n’existe aucune mémoire 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 nombre de colonnes n’ont pas été mis en mémoire tampon).

  • Spécifiez des mémoires tampons de longueur non Null pour les colonnes nullables. La bibliothèque de curseurs alloue des mémoires tampons de longueur dans son cache uniquement si l’argument StrLen_or_IndPtr dans SQLBindCol n’est pas null. Étant donné que SQL_NULL_DATA est stocké dans la mémoire tampon de longueur, la bibliothèque de curseurs part du principe que toute colonne pour laquelle aucune mémoire tampon de longueur n’est spécifiée n’a pas la valeur Null. Si aucune colonne de longueur n’est spécifiée pour une colonne nullable, la bibliothèque de curseurs construit une clause WHERE qui utilise la valeur de données pour la colonne. Cette clause n’identifie pas correctement la ligne.