SQLSetPos, fonction
Conformité
Version introduite : Conformité aux normes ODBC 1.0 : ODBC
Résumé
SQLSetPos définit la position du curseur dans un ensemble de lignes et permet à une application d’actualiser les données de l’ensemble de lignes ou de mettre à jour ou de supprimer des données dans le jeu de résultats.
Syntaxe
SQLRETURN SQLSetPos(
SQLHSTMT StatementHandle,
SQLSETPOSIROW RowNumber,
SQLUSMALLINT Operation,
SQLUSMALLINT LockType);
Arguments
StatementHandle
[Entrée] Handle d’instruction.
RowNumber
[Entrée] Position de la ligne dans l’ensemble de lignes sur laquelle effectuer l’opération spécifiée avec l’argument Opération . Si RowNumber a la valeur 0, l’opération s’applique à chaque ligne de l’ensemble de lignes.
Pour plus d’informations, consultez « Commentaires ».
opération
[Entrée] Opération à effectuer :
SQL_POSITION SQL_REFRESH SQL_UPDATE SQL_DELETE
Notes
La valeur SQL_ADD de l’argument Operation a été déconseillée pour ODBC 3.x. Les pilotes ODBC 3.x devront prendre en charge SQL_ADD pour la compatibilité descendante. Cette fonctionnalité a été remplacée par un appel à SQLBulkOperations avec une opération de SQL_ADD. Lorsqu’une application ODBC 3.x fonctionne avec un pilote ODBC 2.x , le Gestionnaire de pilotes mappe un appel à SQLBulkOperations avec une opération de SQL_ADD à SQLSetPos avec une opération de SQL_ADD.
Pour plus d’informations, consultez « Commentaires ».
LockType
[Entrée] Spécifie comment verrouiller la ligne après avoir effectué l’opération spécifiée dans l’argument Opération .
SQL_LOCK_NO_CHANGE SQL_LOCK_EXCLUSIVE SQL_LOCK_UNLOCK
Pour plus d’informations, consultez « Commentaires ».
Retours
SQL_SUCCESS, SQL_SUCCESS_WITH_INFO, SQL_NEED_DATA, SQL_STILL_EXECUTING, SQL_ERROR ou SQL_INVALID_HANDLE.
Diagnostics
Lorsque SQLSetPos retourne SQL_ERROR ou SQL_SUCCESS_WITH_INFO, une valeur SQLSTATE associée peut être obtenue en appelant SQLGetDiagRec avec un HandleType de SQL_HANDLE_STMT et un handled’instructionHandle. Le tableau suivant répertorie les valeurs SQLSTATE couramment retournées par SQLSetPos et explique chacune d’elles dans le contexte de cette fonction ; La notation « (DM) » précède les descriptions de SQLSTATEs retournées par le Gestionnaire de pilotes. Le code de retour associé à chaque valeur SQLSTATE est SQL_ERROR, sauf indication contraire.
Pour tous les SQLSTATEs qui peuvent retourner SQL_SUCCESS_WITH_INFO ou SQL_ERROR (à l’exception de 01xxx SQLSTATEs), SQL_SUCCESS_WITH_INFO est retourné si une erreur se produit sur une ou plusieurs lignes d’une opération multiligne, mais pas sur la totalité, et SQL_ERROR est retournée si une erreur se produit sur une opération à une seule ligne.
| SQLSTATE | Error | Description |
|---|---|---|
| 01000 | Avertissement général | Message d’information spécifique au pilote. (La fonction retourne SQL_SUCCESS_WITH_INFO.) |
| 01001 | Conflit d’opération de curseur | L’argument Opération a été SQL_DELETE ou SQL_UPDATE, et aucune ligne ou plusieurs lignes n’ont été supprimées ou mises à jour. (Pour plus d’informations sur les mises à jour de plusieurs lignes, consultez la description de l’attribut SQL_ATTR_SIMULATE_CURSOR dans SQLSetStmtAttr.) (La fonction retourne SQL_SUCCESS_WITH_INFO.) L’argument Opération a été SQL_DELETE ou SQL_UPDATE, et l’opération a échoué en raison d’une concurrence optimiste. (La fonction retourne SQL_SUCCESS_WITH_INFO.) |
| 01004 | Troncation droite des données de chaîne | L’argument Opération a été SQL_REFRESH, et les données de chaîne ou binaires retournées pour une ou plusieurs colonnes avec un type de données SQL_C_CHAR ou SQL_C_BINARY ont entraîné la troncation de données binaires non vides ou non NULL. |
| 01S01 | Erreur dans la ligne | L’argument RowNumber était égal à 0 et une erreur s’est produite dans une ou plusieurs lignes lors de l’exécution de l’opération spécifiée avec l’argument Opération. (SQL_SUCCESS_WITH_INFO est retourné si une erreur se produit sur une ou plusieurs lignes, mais pas sur la totalité, d’une opération multiligne, et SQL_ERROR est retourné si une erreur se produit sur une opération à une seule ligne.) (Ce SQLSTATE est retourné uniquement lorsque SQLSetPos est appelé après SQLExtendedFetch, si le pilote est un pilote ODBC 2.x et que la bibliothèque de curseurs n’est pas utilisée.) |
| 01S07 | Troncation fractionnaire | L’argument Opération était SQL_REFRESH, le type de données de la mémoire tampon d’application n’était pas SQL_C_CHAR ou SQL_C_BINARY, et les données retournées aux mémoires tampons d’application pour une ou plusieurs colonnes ont été tronquées. Pour les types de données numériques, la partie fractionnaire du nombre a été tronquée. Pour les types de données time, timestamp et interval contenant un composant de temps, la partie fractionnaire de l’heure a été tronquée. (La fonction retourne SQL_SUCCESS_WITH_INFO.) |
| 07006 | Violation d’attribut de type de données restreint | La valeur de données d’une colonne dans le jeu de résultats n’a pas pu être convertie en type de données spécifié par TargetType dans l’appel à SQLBindCol. |
| 07009 | Index de descripteur non valide | L’argument Operation était SQL_REFRESH ou SQL_UPDATE, et une colonne était liée avec un numéro de colonne supérieur au nombre de colonnes dans le jeu de résultats. |
| 21S02 | Le degré de table dérivée ne correspond pas à la liste de colonnes | L’argument Operation était SQL_UPDATE et aucune colonne n’était modifiable, car toutes les colonnes étaient soit indépendantes, en lecture seule, soit la valeur dans la mémoire tampon de longueur/d’indicateur liée était SQL_COLUMN_IGNORE. |
| 22001 | Données de chaîne, troncation droite | L’argument Operation a été SQL_UPDATE, et l’affectation d’un caractère ou d’une valeur binaire à une colonne a entraîné la troncation de caractères ou d’octets non vides (pour les caractères) ou non null (pour les binaires). |
| 22003 | Valeur numérique hors plage | L’argument Operation a été SQL_UPDATE, et l’affectation d’une valeur numérique à une colonne dans le jeu de résultats a entraîné la tronquation de la partie entière (par opposition à la fraction) du nombre. L’argument Operation a été SQL_REFRESH, et le retour de la valeur numérique pour une ou plusieurs colonnes liées aurait entraîné une perte de chiffres significatifs. |
| 22007 | Format datetime non valide | L’argument Operation a été SQL_UPDATE et l’affectation d’une valeur de date ou d’horodatage à une colonne dans le jeu de résultats a fait que le champ year, month ou day est hors plage. L’argument Opération a été SQL_REFRESH, et le renvoi de la valeur de date ou d’horodatage pour une ou plusieurs colonnes liées aurait fait en sorte que le champ year, month ou day soit hors plage. |
| 22008 | Dépassement de champ de date/heure | L’argument Opération était SQL_UPDATE, et les performances de l’arithmétique datetime sur les données envoyées à une colonne dans le jeu de résultats ont entraîné un champ datetime (année, mois, jour, heure, minute ou deuxième champ) du résultat se trouvant en dehors de la plage autorisée de valeurs pour le champ, ou non valide en fonction des règles naturelles du calendrier grégorien pour les dateheure. L’argument Opération a été SQL_REFRESH, et les performances de l’arithmétique datetime sur les données récupérées à partir du jeu de résultats ont entraîné un champ datetime (année, mois, jour, heure, minute ou deuxième champ) du résultat se trouvant en dehors de la plage de valeurs autorisée pour le champ, ou non valide en fonction des règles naturelles du calendrier grégorien pour les datetimes. |
| 22015 | Dépassement de champ d’intervalle | L’argument Opération a été SQL_UPDATE, et l’affectation d’un type C numérique ou d’intervalle exact à un type de données SQL d’intervalle a entraîné une perte de chiffres significatifs. L’argument Opération a été SQL_UPDATE ; lors de l’affectation à un type SQL d’intervalle, il n’y avait aucune représentation de la valeur du type C dans le type SQL d’intervalle. L’argument Opération a été SQL_REFRESH, et l’affectation d’un type SQL numérique ou d’intervalle exact à un type C d’intervalle a entraîné une perte de chiffres significatifs dans le champ de début. L’argument Operation a été SQL_ REFRESH ; lors de l’affectation à un type C d’intervalle, il n’y avait aucune représentation de la valeur du type SQL dans le type interval C. |
| 22018 | Valeur de caractère non valide pour la spécification de cast | L’argument Opération a été SQL_REFRESH ; le type C était un type de données numérique exact ou approximatif, un datetime ou un type de données d’intervalle ; le type SQL de la colonne était un type de données caractère ; et la valeur de la colonne n’était pas un littéral valide du type C lié. L’argument Operation a été SQL_UPDATE ; le type SQL était un type de données numérique exact ou approximatif, datetime ou intervalle ; le type C a été SQL_C_CHAR ; et la valeur dans la colonne n’était pas un littéral valide du type SQL lié. |
| 23000 | Violation de contrainte d’intégrité | L’argument Operation a été SQL_DELETE ou SQL_UPDATE, et une contrainte d’intégrité a été violée. |
| 24 000 | État de curseur non valide | L’InstructionHandle était dans un état exécuté, mais aucun jeu de résultats n’a été associé à l’InstructionHandle. (DM) Un curseur était ouvert sur l’InstructionHandle, mais SQLFetchScroll n’avait pas été appelé. Un curseur était ouvert sur l’InstructionHandle, et SQLFetchScroll avait été appelé, mais le curseur était positionné avant le début du jeu de résultats ou après la fin du jeu de résultats. L’argument Opération était SQL_DELETE, SQL_REFRESH ou SQL_UPDATE, et le curseur était positionné avant le début du jeu de résultats ou après la fin du jeu de résultats. |
| 40001 | Échec de sérialisation | La transaction a été annulée en raison d’un blocage de ressources avec une autre transaction. |
| 40003 | Saisie semi-automatique d’instruction inconnue | La connexion associée a échoué pendant l’exécution de cette fonction et l’état de la transaction ne peut pas être déterminé. |
| 42000 | Erreur de syntaxe ou violation d’accès | Le pilote n’a pas pu verrouiller la ligne si nécessaire pour effectuer l’opération demandée dans l’argument Opération. Le pilote n’a pas pu verrouiller la ligne comme demandé dans l’argument LockType. |
| 44000 | Violation de WITH CHECK OPTION | L’argument Operation a été SQL_UPDATE, et la mise à jour a été effectuée sur une table consultée ou une table dérivée de la table consultée qui a été créée en spécifiant WITH CHECK OPTION, de sorte qu’une ou plusieurs lignes affectées par la mise à jour ne soient plus présentes dans la table consultée. |
| HY000 | Erreur générale | Une erreur s’est produite pour laquelle il n’y avait pas de SQLSTATE spécifique et pour laquelle aucun SQLSTATE spécifique à l’implémentation n’a été défini. Le message d’erreur retourné par SQLGetDiagRec dans la mémoire tampon *MessageText décrit l’erreur et sa cause. |
| HY001 | Erreur d’allocation de mémoire | Le pilote n’a pas pu allouer la mémoire nécessaire pour prendre en charge l’exécution ou l’achèvement de la fonction. |
| HY008 | Opération annulée | Le traitement asynchrone a été activé pour l’instruction StatementHandle. La fonction a été appelée et, avant de terminer l’exécution, SQLCancel ou SQLCancelHandle a été appelée sur l’InstructionHandle, puis la fonction a été appelée à nouveau sur l’InstructionHandle. La fonction a été appelée et, avant de terminer l’exécution, SQLCancel ou SQLCancelHandle a été appelé sur l’InstructionHandle à partir d’un autre thread dans une application multithread. |
| HY010 | Erreur de séquence de fonction | (DM) Une fonction d’exécution asynchrone a été appelée pour le handle de connexion associé à l’InstructionHandle. Cette fonction asynchrone était toujours en cours d’exécution lorsque la fonction SQLSetPos a été appelée. (DM) L’InstructionHandle spécifiée n’était pas dans un état exécuté. La fonction a été appelée sans appeler d’abord SQLExecDirect, SQLExecute ou une fonction de catalogue. (DM) Une fonction d’exécution asynchrone (et non celle-ci) a été appelée pour l’InstructionHandle et s’exécutait toujours lorsque cette fonction a été appelée. (DM) SQLExecute, SQLExecDirect, SQLBulkOperations ou SQLSetPos a été appelé pour l’InstructionHandle et a renvoyé SQL_NEED_DATA. Cette fonction a été appelée avant l’envoi des données pour toutes les colonnes ou paramètres de données au moment de l’exécution. (DM) Le pilote était un pilote ODBC 2.x , et SQLSetPos a été appelé pour un StatementHandle après l’appel de SQLFetch . |
| HY011 | Impossible de définir l’attribut maintenant | (DM) Le pilote était un pilote ODBC 2.x ; l’attribut d’instruction SQL_ATTR_ROW_STATUS_PTR a été défini ; puis SQLSetPos a été appelé avant l’appel de SQLFetch, SQLFetchScroll ou SQLExtendedFetch . |
| HY013 | Erreur de gestion de la mémoire | L’appel de fonction n’a pas pu être traité, car les objets de mémoire sous-jacents n’ont pas pu être consultés, peut-être en raison de conditions de mémoire insuffisantes. |
| HY090 | Chaîne ou longueur de mémoire tampon non valide | L’argument Operation était SQL_UPDATE, une valeur de données était un pointeur null et la valeur de longueur de colonne n’était pas 0, SQL_DATA_AT_EXEC, SQL_COLUMN_IGNORE, SQL_NULL_DATA ou inférieure ou égale à SQL_LEN_DATA_AT_EXEC_OFFSET. L’argument Operation a été SQL_UPDATE ; une valeur de données n’était pas un pointeur null ; le type de données C était SQL_C_BINARY ou SQL_C_CHAR ; et la valeur de longueur de colonne était inférieure à 0, mais non égale à SQL_DATA_AT_EXEC, SQL_COLUMN_IGNORE, SQL_NTS ou SQL_NULL_DATA, ou inférieure ou égale à SQL_LEN_DATA_AT_EXEC_OFFSET. La valeur d’une mémoire tampon de longueur/indicateur a été SQL_DATA_AT_EXEC ; le type SQL était SQL_LONGVARCHAR, SQL_LONGVARBINARY ou un type de données long spécifique à une source de données ; et le type d’informations SQL_NEED_LONG_DATA_LEN dans SQLGetInfo était « Y ». |
| HY092 | Identificateur d’attribut non valide | (DM) La valeur spécifiée pour l’argument Operation n’était pas valide. (DM) La valeur spécifiée pour l’argument LockType n’était pas valide. L’argument Operation a été SQL_UPDATE ou SQL_DELETE, et l’attribut d’instruction SQL_ATTR_CONCURRENCY a été SQL_ATTR_CONCUR_READ_ONLY. |
| HY107 | Valeur de ligne hors plage | La valeur spécifiée pour l’argument RowNumber était supérieure au nombre de lignes dans l’ensemble de lignes. |
| HY109 | Position du curseur non valide | Le curseur associé à l’InstructionHandle a été défini comme avant uniquement, de sorte que le curseur n’a pas pu être positionné dans l’ensemble de lignes. Consultez la description de l’attribut SQL_ATTR_CURSOR_TYPE dans SQLSetStmtAttr. L’argument Operation a été SQL_UPDATE, SQL_DELETE ou SQL_REFRESH, et la ligne identifiée par l’argument RowNumber a été supprimée ou n’a pas été extraite. (DM) L’argument RowNumber était 0 et l’argument Operation était SQL_POSITION. SQLSetPos a été appelé après l’appel de SQLBulkOperations et avant l’appel de SQLFetchScroll ou SQLFetch . |
| HY117 | La connexion est suspendue en raison d’un état de transaction inconnu. Seules les fonctions de déconnexion et de lecture seule sont autorisées. | (DM) Pour plus d’informations sur l’état suspendu, consultez FONCTION SQLEndTran. |
| HYC00 | Fonctionnalité facultative non implémentée | Le pilote ou la source de données ne prend pas en charge l’opération demandée dans l’argument Operation ou l’argument LockType . |
| HYT00 | Délai expiré | Le délai d’expiration de la requête a expiré avant que la source de données ne retourne le jeu de résultats. Le délai d’expiration est défini via SQLSetStmtAttr avec un attribut de SQL_ATTR_QUERY_TIMEOUT. |
| HYT01 | Délai d’attente de la connexion expiré | Le délai d’expiration de la connexion a expiré avant que la source de données réponde à la demande. La période de délai d’expiration de la connexion est définie via SQLSetConnectAttr, SQL_ATTR_CONNECTION_TIMEOUT. |
| IM001 | Le pilote ne prend pas en charge cette fonction | (DM) Le pilote associé à l’InstructionHandle ne prend pas en charge la fonction. |
| IM017 | L’interrogation est désactivée en mode de notification asynchrone | Chaque fois que le modèle de notification est utilisé, l’interrogation est désactivée. |
| IM018 | SQLCompleteAsync n’a pas été appelé pour effectuer l’opération asynchrone précédente sur ce handle. | Si l’appel de fonction précédent sur le handle retourne SQL_STILL_EXECUTING et si le mode de notification est activé, SQLCompleteAsync doit être appelé sur le handle pour effectuer un post-traitement et terminer l’opération. |
Commentaires
Attention
Pour plus d’informations sur l’instruction indique que SQLSetPos peut être appelé dans et ce qu’il doit faire pour la compatibilité avec les applications ODBC 2.x , consultez Bloquer les curseurs, les curseurs scrollables et la compatibilité descendante.
RowNumber Argument
L’argument RowNumber spécifie le numéro de la ligne dans l’ensemble de lignes sur lequel effectuer l’opération spécifiée par l’argument Operation. Si RowNumber est 0, l’opération s’applique à chaque ligne de l’ensemble de lignes. RowNumber doit être une valeur comprise entre 0 et le nombre de lignes dans l’ensemble de lignes.
Notes
Dans le langage C, les tableaux sont basés sur 0 et l’argument RowNumber est basé sur 1. Par exemple, pour mettre à jour la cinquième ligne de l’ensemble de lignes, une application modifie les mémoires tampons de l’ensemble de lignes à l’index du tableau 4, mais spécifie un RowNumber de 5.
Toutes les opérations placent le curseur sur la ligne spécifiée par RowNumber. Les opérations suivantes nécessitent une position de curseur :
Instructions de mise à jour et de suppression positionnées.
Appelle SQLGetData.
Appelle SQLSetPos avec les options SQL_DELETE, SQL_REFRESH et SQL_UPDATE.
Par exemple, si RowNumber a la valeur 2 pour un appel à SQLSetPos avec une opération de SQL_DELETE, le curseur est positionné sur la deuxième ligne de l’ensemble de lignes et cette ligne est supprimée. L’entrée dans le tableau d’état de ligne d’implémentation (pointée par l’attribut d’instruction SQL_ATTR_ROW_STATUS_PTR) de la deuxième ligne est remplacée par SQL_ROW_DELETED.
Une application peut spécifier une position de curseur lorsqu’elle appelle SQLSetPos. En règle générale, elle appelle SQLSetPos avec l’opération SQL_POSITION ou SQL_REFRESH pour positionner le curseur avant d’exécuter une instruction de mise à jour ou de suppression positionnée ou d’appeler SQLGetData.
Argument d’opération
L’argument Operation prend en charge les opérations suivantes. Pour déterminer les options prises en charge par une source de données, une application appelle SQLGetInfo avec le type d’informations SQL_DYNAMIC_CURSOR_ATTRIBUTES1, SQL_FORWARD_ONLY_CURSOR_ATTRIBUTES1, SQL_KEYSET_CURSOR_ATTRIBUTES1 ou SQL_STATIC_CURSOR_ATTRIBUTES1 (selon le type du curseur).
| opération argument |
Opération |
|---|---|
| SQL_POSITION | Le pilote positionne le curseur sur la ligne spécifiée par RowNumber. Le contenu du tableau d’état de ligne pointé par l’attribut d’instruction SQL_ATTR_ROW_OPERATION_PTR est ignoré pour l’opération SQL_POSITION. |
| SQL_REFRESH | Le pilote positionne le curseur sur la ligne spécifiée par RowNumber et actualise les données dans les mémoires tampons de l’ensemble de lignes pour cette ligne. Pour plus d’informations sur la façon dont le pilote retourne des données dans les mémoires tampons d’ensemble de lignes, consultez les descriptions des liaisons au niveau des lignes et des colonnes dans SQLBindCol. SQLSetPos avec une opération de SQL_REFRESH met à jour l’état et le contenu des lignes dans l’ensemble de lignes extrait actuel. Cela inclut l’actualisation des signets. Étant donné que les données dans les mémoires tampons sont actualisées mais non réétifiées, l’appartenance à l’ensemble de lignes est fixe. Cela diffère de l’actualisation effectuée par un appel à SQLFetchScroll avec un FetchOrientation de SQL_FETCH_RELATIVE et un RowNumber égal à 0, qui refet l’ensemble de lignes du jeu de résultats afin qu’il puisse afficher les données ajoutées et supprimer les données supprimées si ces opérations sont prises en charge par le pilote et le curseur. Une actualisation réussie avec SQLSetPos ne modifie pas l’état d’une ligne de SQL_ROW_DELETED. Les lignes supprimées dans l’ensemble de lignes continueront d’être marquées comme supprimées jusqu’à la prochaine extraction. Les lignes disparaissent lors de l’extraction suivante si le curseur prend en charge l’empaquetage (dans lequel un SQLFetch ou SQLFetchScroll ultérieur ne retourne pas de lignes supprimées). Les lignes ajoutées n’apparaissent pas lorsqu’une actualisation avec SQLSetPos est effectuée. Ce comportement est différent de SQLFetchScroll avec un FetchType de SQL_FETCH_RELATIVE et un RowNumber égal à 0, qui actualise également l’ensemble de lignes actif, mais affiche les enregistrements ajoutés ou empaqueter les enregistrements supprimés si ces opérations sont prises en charge par le curseur. Une actualisation réussie avec SQLSetPos modifie l’état d’une ligne de SQL_ROW_ADDED en SQL_ROW_SUCCESS (si le tableau d’état de ligne existe). Une actualisation réussie avec SQLSetPos modifie l’état d’une ligne de SQL_ROW_UPDATED par le nouvel état de la ligne (si le tableau d’état de ligne existe). Si une erreur se produit dans une opération SQLSetPos sur une ligne, l’état de la ligne est défini sur SQL_ROW_ERROR (si le tableau d’état de ligne existe). Pour un curseur ouvert avec un attribut d’instruction SQL_ATTR_CONCURRENCY SQL_CONCUR_ROWVER ou SQL_CONCUR_VALUES, une actualisation avec SQLSetPos peut mettre à jour les valeurs d’accès concurrentiel optimistes utilisées par la source de données pour détecter que la ligne a changé. Si cela se produit, les versions de ligne ou les valeurs utilisées pour garantir la concurrence des curseurs sont mises à jour chaque fois que les mémoires tampons de l’ensemble de lignes sont actualisées à partir du serveur. Cela se produit pour chaque ligne actualisée. Le contenu du tableau d’état de ligne pointé par l’attribut d’instruction SQL_ATTR_ROW_OPERATION_PTR est ignoré pour l’opération SQL_REFRESH. |
| SQL_UPDATE | Le pilote positionne le curseur sur la ligne spécifiée par RowNumber et met à jour la ligne de données sous-jacente avec les valeurs des mémoires tampons de l’ensemble de lignes (argument TargetValuePtr dans SQLBindCol). Il récupère les longueurs des données des mémoires tampons longueur/indicateur (argument StrLen_or_IndPtr dans SQLBindCol). Si la longueur d’une colonne est SQL_COLUMN_IGNORE, la colonne n’est pas mise à jour. Après la mise à jour de la ligne, le pilote modifie l’élément correspondant du tableau d’état de ligne en SQL_ROW_UPDATED ou SQL_ROW_SUCCESS_WITH_INFO (si le tableau d’état de ligne existe). Le comportement est défini par le pilote si SQLSetPos avec un argument Operation de SQL_UPDATE est appelé sur un curseur qui contient des colonnes en double. Le pilote peut retourner un SQLSTATE défini par le pilote, mettre à jour la première colonne qui apparaît dans le jeu de résultats ou effectuer un autre comportement défini par le pilote. Le tableau d’opérations de ligne pointé par l’attribut d’instruction SQL_ATTR_ROW_OPERATION_PTR peut être utilisé pour indiquer qu’une ligne de l’ensemble de lignes actif doit être ignorée lors d’une mise à jour en bloc. Pour plus d’informations, consultez « Tableaux d’état et d’opérations » plus loin dans cette référence de fonction. |
| SQL_DELETE | Le pilote positionne le curseur sur la ligne spécifiée par RowNumber et supprime la ligne de données sous-jacente. Il modifie l’élément correspondant du tableau d’état de ligne en SQL_ROW_DELETED. Une fois la ligne supprimée, les éléments suivants ne sont pas valides pour la ligne : instructions de mise à jour et de suppression positionnées, appels à SQLGetData et appels à SQLSetPos avec Operation défini sur n’importe quoi, sauf SQL_POSITION. Pour les pilotes qui prennent en charge l’empaquetage, la ligne est supprimée du curseur lorsque de nouvelles données sont récupérées à partir de la source de données. Le fait que la ligne reste visible dépend du type de curseur. Par exemple, les lignes supprimées sont visibles pour les curseurs statiques et pilotés par un jeu de clés, mais invisibles pour les curseurs dynamiques. Le tableau d’opération de ligne pointé par l’attribut d’instruction SQL_ATTR_ROW_OPERATION_PTR peut être utilisé pour indiquer qu’une ligne de l’ensemble de lignes actif doit être ignorée lors d’une suppression en bloc. Pour plus d’informations, consultez « Tableaux d’état et d’opérations » plus loin dans cette référence de fonction. |
LockType, argument
L’argument LockType permet aux applications de contrôler l’accès concurrentiel. Dans la plupart des cas, les sources de données qui prennent en charge les niveaux d’accès concurrentiel et les transactions prennent uniquement en charge la valeur SQL_LOCK_NO_CHANGE de l’argument LockType . L’argument LockType est généralement utilisé uniquement pour la prise en charge basée sur les fichiers.
L’argument LockType spécifie l’état de verrouillage de la ligne après l’exécution de SQLSetPos. Si le pilote ne parvient pas à verrouiller la ligne pour effectuer l’opération demandée ou pour satisfaire l’argument LockType , il retourne SQL_ERROR et SQLSTATE 42000 (erreur de syntaxe ou violation d’accès).
Bien que l’argument LockType soit spécifié pour une instruction unique, le verrou accorde les mêmes privilèges à toutes les instructions de la connexion. En particulier, un verrou acquis par une instruction sur une connexion peut être déverrouillé par une autre instruction sur la même connexion.
Une ligne verrouillée via SQLSetPos reste verrouillée jusqu’à ce que l’application appelle SQLSetPos pour la ligne avec LockType définie sur SQL_LOCK_UNLOCK, ou jusqu’à ce que l’application appelle SQLFreeHandle pour l’instruction ou SQLFreeStmt avec l’option SQL_CLOSE. Pour un pilote qui prend en charge les transactions, une ligne verrouillée via SQLSetPos est déverrouillée lorsque l’application appelle SQLEndTran pour valider ou restaurer une transaction sur la connexion (si un curseur est fermé lorsqu’une transaction est validée ou restaurée, comme indiqué par les types d’informations SQL_CURSOR_COMMIT_BEHAVIOR et SQL_CURSOR_ROLLBACK_BEHAVIOR retournés par SQLGetInfo).
L’argument LockType prend en charge les types de verrous suivants. Pour déterminer les verrous pris en charge par une source de données, une application appelle SQLGetInfo avec le type d’informations SQL_DYNAMIC_CURSOR_ATTRIBUTES1, SQL_FORWARD_ONLY_CURSOR_ATTRIBUTES1, SQL_KEYSET_CURSOR_ATTRIBUTES1 ou SQL_STATIC_CURSOR_ATTRIBUTES1 (selon le type du curseur).
| Argument LockType | Type de verrou |
|---|---|
| SQL_LOCK_NO_CHANGE | Le pilote ou la source de données garantit que la ligne est dans le même état verrouillé ou déverrouillé qu’avant l’appel de SQLSetPos . Cette valeur lockType permet aux sources de données qui ne prennent pas en charge le verrouillage explicite au niveau des lignes d’utiliser le verrouillage requis par les niveaux actuels d’isolation des transactions et d’accès concurrentiel. |
| SQL_LOCK_EXCLUSIVE | Le pilote ou la source de données verrouille la ligne exclusivement. Une instruction sur une autre connexion ou dans une autre application ne peut pas être utilisée pour acquérir des verrous sur la ligne. |
| SQL_LOCK_UNLOCK | Le pilote ou la source de données déverrouille la ligne. |
Si un pilote prend en charge SQL_LOCK_EXCLUSIVE mais ne prend pas en charge SQL_LOCK_UNLOCK, une ligne verrouillée reste verrouillée jusqu’à ce que l’un des appels de fonction décrits dans le paragraphe précédent se produise.
Si un pilote prend en charge SQL_LOCK_EXCLUSIVE mais ne prend pas en charge les SQL_LOCK_UNLOCK, une ligne verrouillée reste verrouillée jusqu’à ce que l’application appelle SQLFreeHandle pour l’instruction ou SQLFreeStmt avec l’option SQL_CLOSE. Si le pilote prend en charge les transactions et ferme le curseur lors de la validation ou de la restauration de la transaction, l’application appelle SQLEndTran.
Pour les opérations de mise à jour et de suppression dans SQLSetPos, l’application utilise l’argument LockType comme suit :
Pour garantir qu’une ligne ne change pas après sa récupération, une application appelle SQLSetPos avec Operation défini sur SQL_REFRESH et LockType défini sur SQL_LOCK_EXCLUSIVE.
Si l’application définit LockType sur SQL_LOCK_NO_CHANGE, le pilote garantit qu’une opération de mise à jour ou de suppression réussira uniquement si l’application spécifiée SQL_CONCUR_LOCK pour l’attribut d’instruction SQL_ATTR_CONCURRENCY.
Si l’application spécifie SQL_CONCUR_ROWVER ou SQL_CONCUR_VALUES pour l’attribut d’instruction SQL_ATTR_CONCURRENCY, le pilote compare les versions de ligne ou les valeurs et rejette l’opération si la ligne a changé depuis que l’application a extrait la ligne.
Si l’application spécifie SQL_CONCUR_READ_ONLY pour l’attribut d’instruction SQL_ATTR_CONCURRENCY, le pilote rejette toute opération de mise à jour ou de suppression.
Pour plus d’informations sur l’attribut d’instruction SQL_ATTR_CONCURRENCY, consultez SQLSetStmtAttr.
Tableaux d’état et d’opérations
Les tableaux d’état et d’opérations suivants sont utilisés lors de l’appel de SQLSetPos :
Le tableau d’état de ligne (comme indiqué par le champ SQL_DESC_ARRAY_STATUS_PTR dans l’IRD et l’attribut d’instruction SQL_ATTR_ROW_STATUS_ARRAY) contient des valeurs d’état pour chaque ligne de données dans l’ensemble de lignes. Le pilote définit les valeurs d’état dans ce tableau après un appel à SQLFetch, SQLFetchScroll, SQLBulkOperations ou SQLSetPos. Ce tableau est pointé vers l’attribut d’instruction SQL_ATTR_ROW_STATUS_PTR.
Le tableau d’opérations de ligne (comme indiqué par le champ SQL_DESC_ARRAY_STATUS_PTR dans l’ARD et l’attribut d’instruction SQL_ATTR_ROW_OPERATION_ARRAY) contient une valeur pour chaque ligne de l’ensemble de lignes qui indique si un appel à SQLSetPos pour une opération en bloc est ignoré ou effectué. Chaque élément du tableau est défini sur SQL_ROW_PROCEED (valeur par défaut) ou SQL_ROW_IGNORE. Ce tableau est pointé vers l’attribut d’instruction SQL_ATTR_ROW_OPERATION_PTR.
Le nombre d’éléments dans les tableaux d’état et d’opération doit être égal au nombre de lignes dans l’ensemble de lignes (tel que défini par l’attribut d’instruction SQL_ATTR_ROW_ARRAY_SIZE).
Pour plus d’informations sur le tableau d’état des lignes, consultez SQLFetch. Pour plus d’informations sur le tableau d’opérations de ligne, consultez « Ignorer une ligne dans une opération en bloc », plus loin dans cette section.
Utilisation de SQLSetPos
Avant qu’une application appelle SQLSetPos, elle doit effectuer la séquence d’étapes suivante :
Si l’application appelle SQLSetPos avec Operation définie sur SQL_UPDATE, appelez SQLBindCol (ou SQLSetDescRec) pour chaque colonne afin de spécifier son type de données et de lier les mémoires tampons pour les données et la longueur de la colonne.
Si l’application appelle SQLSetPos avec Operation définie sur SQL_DELETE ou SQL_UPDATE, appelez SQLColAttribute pour vous assurer que les colonnes à supprimer ou à mettre à jour sont modifiables.
Appelez SQLExecDirect, SQLExecute ou une fonction de catalogue pour créer un jeu de résultats.
Appelez SQLFetch ou SQLFetchScroll pour récupérer les données.
Pour plus d’informations sur l’utilisation de SQLSetPos, consultez Mise à jour des données avec SQLSetPos.
Suppression de données à l’aide de SQLSetPos
Pour supprimer des données avec SQLSetPos, une application appelle SQLSetPos avec RowNumber défini sur le numéro de la ligne à supprimer et Operation défini sur SQL_DELETE.
Une fois les données supprimées, le pilote modifie la valeur dans le tableau d’état des lignes d’implémentation pour la ligne appropriée en SQL_ROW_DELETED (ou SQL_ROW_ERROR).
Mise à jour des données à l’aide de SQLSetPos
Une application peut passer la valeur d’une colonne dans la mémoire tampon de données liée ou avec un ou plusieurs appels à SQLPutData. Les colonnes dont les données sont transmises avec SQLPutData sont appelées colonnesde données à l’exécution. Ils sont couramment utilisés pour envoyer des données pour les colonnes SQL_LONGVARBINARY et SQL_LONGVARCHAR et peuvent être mélangés avec d’autres colonnes.
Pour mettre à jour des données avec SQLSetPos, une application :
Place les valeurs dans les mémoires tampons de données et de longueur/indicateur liées à SQLBindCol :
Pour les colonnes normales, l’application place la nouvelle valeur de colonne dans la mémoire tampon *TargetValuePtr et la longueur de cette valeur dans la mémoire tampon *StrLen_or_IndPtr . Si la ligne ne doit pas être mise à jour, l’application place SQL_ROW_IGNORE dans l’élément de cette ligne du tableau d’opérations de ligne.
Pour les colonnes data-at-execution, l’application place une valeur définie par l’application, telle que le numéro de colonne, dans la mémoire tampon *TargetValuePtr . La valeur peut être utilisée ultérieurement pour identifier la colonne.
L’application place le résultat de la macro SQL_LEN_DATA_AT_EXEC(length) dans la mémoire tampon *StrLen_or_IndPtr . Si le type de données SQL de la colonne est SQL_LONGVARBINARY, SQL_LONGVARCHAR ou un type de données long spécifique à la source de données et que le pilote retourne « Y » pour le type d’informations SQL_NEED_LONG_DATA_LEN dans SQLGetInfo, la longueur correspond au nombre d’octets de données à envoyer pour le paramètre ; sinon, il doit s’agir d’une valeur non négative et est ignorée.
Appelle SQLSetPos avec l’argument Operation défini sur SQL_UPDATE pour mettre à jour la ligne de données.
S’il n’existe aucune colonne data-at-execution, le processus est terminé.
S’il existe des colonnes data-at-execution, la fonction retourne SQL_NEED_DATA et passe à l’étape 3.
Appelle SQLParamData pour récupérer l’adresse de la mémoire tampon *TargetValuePtr pour la première colonne data-at-execution à traiter. SQLParamData retourne SQL_NEED_DATA. L’application récupère la valeur définie par l’application à partir de la mémoire tampon *TargetValuePtr .
Notes
Bien que les paramètres data-at-execution soient similaires aux colonnes data-at-execution, la valeur retournée par SQLParamData est différente pour chacune d’elles.
Notes
Les paramètres data-at-execution sont des paramètres d’une instruction SQL pour lesquels les données sont envoyées avec SQLPutData lorsque l’instruction est exécutée avec SQLExecDirect ou SQLExecute. Ils sont liés à SQLBindParameter ou en définissant des descripteurs avec SQLSetDescRec. La valeur retournée par SQLParamData est une valeur 32 bits passée à SQLBindParameter dans l’argument ParameterValuePtr .
Notes
Les colonnes data-at-execution sont des colonnes d’un ensemble de lignes pour lesquelles des données sont envoyées avec SQLPutData lorsqu’une ligne est mise à jour avec SQLSetPos. Ils sont liés à SQLBindCol. La valeur retournée par SQLParamData est l’adresse de la ligne dans la mémoire tampon *TargetValuePtr en cours de traitement.
Appelle SQLPutData une ou plusieurs fois pour envoyer des données pour la colonne. Plusieurs appels sont nécessaires si toutes les valeurs de données ne peuvent pas être retournées dans la mémoire tampon *TargetValuePtr spécifiée dans SQLPutData ; plusieurs appels à SQLPutData pour la même colonne sont autorisés uniquement lors de l’envoi de données de caractère C à une colonne avec un type de données spécifique à la source de données, ou lors de l’envoi de données binaires C à une colonne avec un type de données caractère, binaire ou spécifique à la source de données.
Appelle à nouveau SQLParamData pour signaler que toutes les données ont été envoyées pour la colonne.
S’il existe davantage de colonnes de données à l’exécution, SQLParamData retourne SQL_NEED_DATA et l’adresse de la mémoire tampon TargetValuePtr pour la colonne de données à l’exécution suivante à traiter. L’application répète les étapes 4 et 5.
S’il n’y a plus de colonnes de données à l’exécution, le processus est terminé. Si l’instruction a été exécutée correctement, SQLParamData retourne SQL_SUCCESS ou SQL_SUCCESS_WITH_INFO ; si l’exécution a échoué, elle retourne SQL_ERROR. À ce stade, SQLParamData peut retourner n’importe quel SQLSTATE qui peut être retourné par SQLSetPos.
Si les données ont été mises à jour, le pilote modifie la valeur dans le tableau d’état des lignes d’implémentation pour la ligne appropriée en SQL_ROW_UPDATED.
Si l’opération est annulée ou si une erreur se produit dans SQLParamData ou SQLPutData, une fois que SQLSetPos retourne SQL_NEED_DATA et avant que les données soient envoyées pour toutes les colonnes de données à l’exécution, l’application peut appeler uniquement SQLCancel, SQLGetDiagField, SQLGetDiagRec, SQLGetFunctions, SQLParamData ou SQLPutData pour l’instruction ou la connexion associée à l’instruction. Si elle appelle une autre fonction pour l’instruction ou la connexion associée à l’instruction, la fonction retourne SQL_ERROR et SQLSTATE HY010 (erreur de séquence de fonction).
Si l’application appelle SQLCancel alors que le pilote a toujours besoin de données pour les colonnes de données à l’exécution, le pilote annule l’opération. L’application peut ensuite appeler à nouveau SQLSetPos ; l’annulation n’affecte pas l’état du curseur ou la position actuelle du curseur.
Lorsque la liste SELECT de la spécification de requête associée au curseur contient plusieurs références à la même colonne, si une erreur est générée ou si le pilote ignore les références dupliquées et effectue les opérations demandées est défini par le pilote.
Exécution d’opérations en bloc
Si l’argument RowNumber a la valeur 0, le pilote effectue l’opération spécifiée dans l’argument Operation pour chaque ligne de l’ensemble de lignes qui a la valeur SQL_ROW_PROCEED dans son champ dans le tableau d’opérations de ligne pointé vers SQL_ATTR_ROW_OPERATION_PTR attribut d’instruction. Il s’agit d’une valeur valide de l’argument RowNumber pour un argument Operation de SQL_DELETE, SQL_REFRESH ou SQL_UPDATE, mais pas SQL_POSITION. SQLSetPos avec une opération de SQL_POSITION et un RowNumber égal à 0 retourneNT SQLSTATE HY109 (position de curseur non valide).
Si une erreur se produit concernant l’ensemble de l’ensemble de lignes, par exemple SQLSTATE HYT00 (délai d’expiration), le pilote retourne SQL_ERROR et le SQLSTATE approprié. Le contenu des mémoires tampons d’ensemble de lignes n’est pas défini et la position du curseur est inchangée.
Si une erreur se produit concernant une seule ligne, le pilote :
Définit l’élément de la ligne dans le tableau d’état de ligne pointé vers l’attribut d’instruction SQL_ATTR_ROW_STATUS_PTR sur SQL_ROW_ERROR.
Publie un ou plusieurs SQLSTATE supplémentaires pour l’erreur dans la file d’attente d’erreurs et définit le champ SQL_DIAG_ROW_NUMBER dans la structure des données de diagnostic.
Une fois l’erreur ou l’avertissement traité, si le pilote termine l’opération pour les lignes restantes de l’ensemble de lignes, il retourne SQL_SUCCESS_WITH_INFO. Par conséquent, pour chaque ligne qui a retourné une erreur, la file d’attente d’erreurs contient zéro ou plusieurs SQLSTATEs supplémentaires. Si le pilote arrête l’opération après avoir traité l’erreur ou l’avertissement, il retourne SQL_ERROR.
Si le pilote retourne des avertissements, tels que SQLSTATE 01004 (données tronquées), il retourne des avertissements qui s’appliquent à l’ensemble de lignes entier ou aux lignes inconnues de l’ensemble de lignes avant de renvoyer les informations d’erreur qui s’appliquent à des lignes spécifiques. Il retourne des avertissements pour des lignes spécifiques ainsi que toute autre information d’erreur sur ces lignes.
Si RowNumber est égal à 0 et que Operation est SQL_UPDATE, SQL_REFRESH ou SQL_DELETE, le nombre de lignes sur lesquelles SQLSetPos opère est pointé vers l’attribut d’instruction SQL_ATTR_ROWS_FETCHED_PTR.
Si RowNumber est égal à 0 et que Operation est SQL_DELETE, SQL_REFRESH ou SQL_UPDATE, la ligne actuelle après l’opération est identique à la ligne actuelle avant l’opération.
Ignorer une ligne dans une opération en bloc
Le tableau d’opérations de ligne peut être utilisé pour indiquer qu’une ligne de l’ensemble de lignes actif doit être ignorée lors d’une opération en bloc à l’aide de SQLSetPos. Pour indiquer au pilote d’ignorer une ou plusieurs lignes pendant une opération en bloc, une application doit effectuer les étapes suivantes :
Appelez SQLSetStmtAttr pour définir l’attribut d’instruction SQL_ATTR_ROW_OPERATION_PTR pour qu’il pointe vers un tableau de SQLUSMALLINTs. Ce champ peut également être défini en appelant SQLSetDescField pour définir le champ d’en-tête SQL_DESC_ARRAY_STATUS_PTR de l’ARD, ce qui nécessite qu’une application obtienne le handle de descripteur.
Définissez chaque élément du tableau d’opérations de ligne sur l’une des deux valeurs suivantes :
SQL_ROW_IGNORE, pour indiquer que la ligne est exclue pour l’opération en bloc.
SQL_ROW_PROCEED, pour indiquer que la ligne est incluse dans l’opération en bloc. (Il s'agit de la valeur par défaut.)
Appelez SQLSetPos pour effectuer l’opération en bloc.
Les règles suivantes s’appliquent au tableau d’opérations de ligne :
SQL_ROW_IGNORE et SQL_ROW_PROCEED affectent uniquement les opérations en bloc à l’aide de SQLSetPos avec une opération de SQL_DELETE ou de SQL_UPDATE. Elles n’affectent pas les appels à SQLSetPos avec une opération de SQL_REFRESH ou de SQL_POSITION.
Le pointeur est défini sur null par défaut.
Si le pointeur a la valeur Null, toutes les lignes sont mises à jour comme si tous les éléments étaient définis sur SQL_ROW_PROCEED.
La définition d’un élément sur SQL_ROW_PROCEED ne garantit pas que l’opération se produira sur cette ligne particulière. Par exemple, si une certaine ligne de l’ensemble de lignes a l’état SQL_ROW_ERROR, le pilote peut ne pas être en mesure de mettre à jour cette ligne, que l’application ait ou non spécifié SQL_ROW_PROCEED. Une application doit toujours vérifier le tableau d’état des lignes pour voir si l’opération a réussi.
SQL_ROW_PROCEED est défini comme 0 dans le fichier d’en-tête. Une application peut initialiser le tableau d’opérations de ligne sur 0 afin de traiter toutes les lignes.
Si le numéro d’élément « n » dans le tableau d’opérations de ligne est défini sur SQL_ROW_IGNORE et que SQLSetPos est appelé pour effectuer une opération de mise à jour ou de suppression en bloc, la nième ligne de l’ensemble de lignes reste inchangée après l’appel à SQLSetPos.
Une application doit automatiquement définir une colonne en lecture seule sur SQL_ROW_IGNORE.
Ignorer une colonne dans une opération en bloc
Pour éviter le traitement inutile des diagnostics générés par les tentatives de mise à jour d’une ou de plusieurs colonnes en lecture seule, une application peut définir la valeur dans la mémoire tampon de longueur/d’indicateur liée sur SQL_COLUMN_IGNORE. Pour plus d’informations, consultez SQLBindCol.
Exemple de code
Dans l’exemple suivant, une application permet à un utilisateur de parcourir la table ORDERS et de mettre à jour l’état des commandes. Le curseur est piloté par un jeu de clés avec une taille d’ensemble de lignes de 20 et utilise un contrôle d’accès concurrentiel optimiste comparant les versions de lignes. Une fois chaque ensemble de lignes extrait, l’application l’imprime et permet à l’utilisateur de sélectionner et de mettre à jour l’état d’une commande. L’application utilise SQLSetPos pour positionner le curseur sur la ligne sélectionnée et effectue une mise à jour positionnée de la ligne. (La gestion des erreurs est omise pour des fins de clarté.)
#define ROWS 20
#define STATUS_LEN 6
SQLCHAR szStatus[ROWS][STATUS_LEN], szReply[3];
SQLINTEGER cbStatus[ROWS], cbOrderID;
SQLUSMALLINT rgfRowStatus[ROWS];
SQLUINTEGER sOrderID, crow = ROWS, irow;
SQLHSTMT hstmtS, hstmtU;
SQLSetStmtAttr(hstmtS, SQL_ATTR_CONCURRENCY, (SQLPOINTER) SQL_CONCUR_ROWVER, 0);
SQLSetStmtAttr(hstmtS, SQL_ATTR_CURSOR_TYPE, (SQLPOINTER) SQL_CURSOR_KEYSET_DRIVEN, 0);
SQLSetStmtAttr(hstmtS, SQL_ATTR_ROW_ARRAY_SIZE, (SQLPOINTER) ROWS, 0);
SQLSetStmtAttr(hstmtS, SQL_ATTR_ROW_STATUS_PTR, (SQLPOINTER) rgfRowStatus, 0);
SQLSetCursorName(hstmtS, "C1", SQL_NTS);
SQLExecDirect(hstmtS, "SELECT ORDERID, STATUS FROM ORDERS ", SQL_NTS);
SQLBindCol(hstmtS, 1, SQL_C_ULONG, &sOrderID, 0, &cbOrderID);
SQLBindCol(hstmtS, 2, SQL_C_CHAR, szStatus, STATUS_LEN, &cbStatus);
while ((retcode == SQLFetchScroll(hstmtS, SQL_FETCH_NEXT, 0)) != SQL_ERROR) {
if (retcode == SQL_NO_DATA_FOUND)
break;
for (irow = 0; irow < crow; irow++) {
if (rgfRowStatus[irow] != SQL_ROW_DELETED)
printf("%2d %5d %*s\n", irow+1, sOrderID, NAME_LEN-1, szStatus[irow]);
}
while (TRUE) {
printf("\nRow number to update?");
gets_s(szReply, 3);
irow = atoi(szReply);
if (irow > 0 && irow <= crow) {
printf("\nNew status?");
gets_s(szStatus[irow-1], (ROWS * STATUS_LEN));
SQLSetPos(hstmtS, irow, SQL_POSITION, SQL_LOCK_NO_CHANGE);
SQLPrepare(hstmtU,
"UPDATE ORDERS SET STATUS=? WHERE CURRENT OF C1", SQL_NTS);
SQLBindParameter(hstmtU, 1, SQL_PARAM_INPUT,
SQL_C_CHAR, SQL_CHAR,
STATUS_LEN, 0, szStatus[irow], 0, NULL);
SQLExecute(hstmtU);
} else if (irow == 0) {
break;
}
}
}
Pour plus d’exemples, consultez Instructions de mise à jour et de suppression positionnées et Mise à jour des lignes dans l’ensemble de lignes avec SQLSetPos.
Fonctions connexes
| Pour obtenir des informations sur | Consultez |
|---|---|
| Liaison d’une mémoire tampon à une colonne dans un jeu de résultats | Fonction SQLBindCol |
| Exécution d’opérations en bloc qui ne sont pas liées à la position du curseur de bloc | SQLBulkOperations, fonction |
| Annulation du traitement des instructions | SQLCancel, fonction |
| Extraction d’un bloc de données ou défilement d’un jeu de résultats | Fonction SQLFetchScroll |
| Obtention d’un champ unique d’un descripteur | Fonction SQLGetDescField |
| Obtention de plusieurs champs d’un descripteur | SQLGetDescRec, fonction |
| Définition d’un champ unique d’un descripteur | SQLSetDescField, fonction |
| Définition de plusieurs champs d’un descripteur | SQLSetDescRec, fonction |
| Définition d’un attribut d’instruction | Fonction SQLSetStmtAttr |
Voir aussi
Informations de référence sur l’API ODBC
Fichiers d’en-tête ODBC
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour