Recordset : informations complémentaires sur les mises à jour (ODBC)

Cette rubrique s’applique aux classes ODBC MFC.

Cette rubrique explique :

• Comment d’autres opérations, telles que les transactions, affectent les mises à jour.

• Vos mises à jour et celles d’autres utilisateurs.

• En savoir plus sur les fonctions membres Update and Delete.

Remarque

Cette rubrique s’applique aux objets dérivés de CRecordset où l’extraction de lignes en bloc n’a pas été implémentée. Si vous avez implémenté la récupération de lignes en bloc, certaines informations ne s’appliquent pas. Par exemple, vous ne pouvez pas appeler les AddNewfonctions , , EditDeleteet Update membres ; toutefois, vous pouvez effectuer des transactions. Pour plus d’informations sur l’extraction de lignes en bloc, consultez Recordset : Extraction d’enregistrements en bloc (ODBC).

Impact des autres opérations sur les mises à jour

Vos mises à jour sont affectées par les transactions en vigueur au moment de la mise à jour, en fermant le jeu d’enregistrements avant la fin d’une transaction, et en faisant défiler l’écran avant la fin d’une transaction.

Impact des transactions sur les mises à jour

Au-delà de comprendre comment, et de AddNewtravailler, il est important de comprendre comment les BeginTransfonctions membres CommitTransde Rollback CDatabase fonctionnent avec les fonctions de mise à jour de CRecordset.Delete Edit

Par défaut, les appels à AddNew et Edit affectent la source de données immédiatement lorsque vous appelez Update. Delete les appels prennent effet immédiatement. Toutefois, vous pouvez établir une transaction et exécuter un lot de ces appels. Les mises à jour ne sont pas permanentes tant que vous ne les validez pas. Si vous changez d’avis, vous pouvez restaurer la transaction au lieu de la valider.

Pour plus d’informations sur les transactions, consultez Transaction (ODBC).

Comment la fermeture du jeu d’enregistrements affecte les mises à jour

Si vous fermez un jeu d’enregistrements ou son objet associé CDatabase , avec une transaction en cours (vous n’avez pas appelé CDatabase ::CommitTrans ou CDatabase ::Rollback), la transaction est restaurée automatiquement (sauf si votre serveur principal de base de données est le moteur de base de données Microsoft Jet).

Attention

Si vous utilisez le moteur de base de données Microsoft Jet, la fermeture d’un jeu d’enregistrements à l’intérieur d’une transaction explicite n’entraîne pas la libération d’une des lignes qui ont été modifiées ou verrouillées jusqu’à ce que la transaction explicite soit validée ou restaurée. Il est recommandé de toujours ouvrir et fermer des jeux d’enregistrements à l’intérieur ou à l’extérieur d’une transaction Jet explicite.

Comment le défilement affecte les mises à jour

Lorsque vous recordset : défilement (ODBC) dans un jeu d’enregistrements, la mémoire tampon d’édition est remplie avec chaque nouvel enregistrement actif (l’enregistrement précédent n’est pas stocké en premier). Le défilement ignore les enregistrements précédemment supprimés. Si vous faites défiler après un AddNew appel ou Edit un appel sans appeler Update, CommitTransou Rollback tout d’abord, toutes les modifications sont perdues (sans avertissement pour vous) car un nouvel enregistrement est introduit dans la mémoire tampon de modification. La mémoire tampon d’édition est remplie avec l’enregistrement qui fait défiler l’enregistrement, l’enregistrement stocké est libéré et aucune modification ne se produit sur la source de données. Cela s’applique à AddNew et à Edit.

Vos mises à jour et les mises à jour d’autres utilisateurs

Lorsque vous utilisez un jeu d’enregistrements pour mettre à jour les données, vos mises à jour affectent d’autres utilisateurs. De même, les mises à jour d’autres utilisateurs pendant la durée de vie de votre jeu d’enregistrements vous affectent.

Dans un environnement multiutilisateur, d’autres utilisateurs peuvent ouvrir des jeux d’enregistrements qui contiennent certains des mêmes enregistrements que ceux que vous avez sélectionnés dans votre jeu d’enregistrements. Les modifications apportées à un enregistrement avant de le récupérer sont reflétées dans votre jeu d’enregistrements. Étant donné que les feuilles de réponse dynamique récupèrent un enregistrement chaque fois que vous faites défiler vers celui-ci, les feuilles de réponse reflètent les modifications chaque fois que vous faites défiler vers un enregistrement. Les instantanés récupèrent un enregistrement la première fois que vous faites défiler vers celui-ci, de sorte que les instantanés reflètent uniquement les modifications qui se produisent avant de faire défiler l’enregistrement au départ.

Les enregistrements ajoutés par d’autres utilisateurs après avoir ouvert le jeu d’enregistrements ne s’affichent pas dans votre jeu d’enregistrements, sauf si vous effectuez une nouvelle requête. Si votre jeu d’enregistrements est une feuille de réponse dynamique, les modifications des enregistrements existants par d’autres utilisateurs s’affichent dans votre jeu de feuilles dynamiques lorsque vous faites défiler vers l’enregistrement affecté. Si votre jeu d’enregistrements est un instantané, les modifications ne s’affichent pas tant que vous n’avez pas réexécuté l’instantané. Si vous souhaitez voir les enregistrements ajoutés ou supprimés par d’autres utilisateurs dans votre instantané, ou les enregistrements ajoutés par d’autres utilisateurs dans votre feuille de réponse dynamique, appelez CRecordset ::Requery pour reconstruire le jeu d’enregistrements. (Notez que les suppressions d’autres utilisateurs s’affichent dans votre dynaset.) Vous pouvez également appeler Requery pour voir les enregistrements que vous ajoutez, mais pas pour voir vos suppressions.

Conseil

Pour forcer la mise en cache d’un instantané entier à la fois, appelez MoveLast immédiatement après l’ouverture de l’instantané. Appelez MoveFirst ensuite pour commencer à utiliser les enregistrements. MoveLast équivaut à faire défiler tous les enregistrements, mais il les récupère à la fois. Notez toutefois que cela peut réduire les performances et peut ne pas être nécessaire pour certains pilotes.

Les effets de vos mises à jour sur d’autres utilisateurs sont similaires à leurs effets sur vous.

En savoir plus sur la mise à jour et la suppression

Cette section fournit des informations supplémentaires pour vous aider à travailler avec Update et Delete.

Réussite et échec de la mise à jour

En Update cas de réussite, le ou Edit le AddNew mode se termine. Pour recommencer un ou Edit un AddNew mode, appelez AddNew ou Edit.

En Update cas d’échec (retourne FALSE ou lève une exception), vous restez en mode ou Edit en AddNew mode, selon la fonction que vous avez appelée en dernier. Vous pouvez alors effectuer l’une des opérations suivantes :

• Modifiez un membre de données de champ et réessayez Update .

• Appelez AddNew pour réinitialiser les membres de données de champ sur Null, définissez les valeurs des membres de données de champ, puis appelez Update à nouveau.

• Appelez Edit pour recharger les valeurs qui étaient dans le jeu d’enregistrements avant le premier appel vers AddNew ou Edit, définissez les valeurs des membres de données de champ, puis appelez Update à nouveau. Après un appel réussi Update (sauf après un AddNew appel), les membres de données de champ conservent leurs nouvelles valeurs.

• Appel Move (y compris Move avec un paramètre de AFX_MOVE_REFRESH, ou 0), qui vide toutes les modifications et met fin à tout AddNew ou Edit mode en vigueur.

Mettre à jour et supprimer

Cette section s’applique aux deux Update et Deleteaux deux.

Sur une Update ou Delete une opération, un seul enregistrement doit être mis à jour. Cet enregistrement est l’enregistrement actif, qui correspond aux valeurs de données dans les champs du jeu d’enregistrements. Si, pour une raison quelconque, aucun enregistrement n’est affecté ou que plusieurs enregistrements sont affectés, une exception est levée contenant l’une des valeurs RETCODE suivantes :

• AFX_SQL_ERROR_NO_ROWS_AFFECTED

• AFX_SQL_ERROR_MULTIPLE_ROWS_AFFECTED

Lorsque ces exceptions sont levées, vous restez dans l’état dans Edit lequel AddNew vous étiez lorsque vous avez appelé Update ou Delete. Voici les scénarios les plus courants dans lesquels vous verrez ces exceptions. Vous êtes le plus susceptible de voir :

• AFX_SQL_ERROR_NO_ROWS_AFFECTED lorsque vous utilisez le mode de verrouillage optimiste et qu’un autre utilisateur a modifié l’enregistrement de manière à empêcher l’infrastructure d’identifier l’enregistrement approprié à mettre à jour ou à supprimer.

• AFX_SQL_ERROR_MULTIPLE_ROWS_AFFECTED lorsque la table que vous mettez à jour n’a pas de clé primaire ou d’index unique et que vous n’avez pas suffisamment de colonnes dans le jeu d’enregistrements pour identifier de manière unique une ligne de table.

Voir aussi

Recordset (ODBC)
Recordset : sélection d’enregistrements par les recordsets (ODBC)
Record Field Exchange (RFX)
SQL
Exceptions : exceptions de base de données