Partager via

Réenregistrer des données dans la base de données dans des applications .NET Framework

  • Article

Remarque

Les jeux de données et les classes associées sont des technologies .NET Framework héritées qui datent du début des années 2000. Elles permettent aux applications d’utiliser des données en mémoire pendant que les applications sont déconnectées de la base de données. Ces technologies sont particulièrement utiles aux applications qui permettent aux utilisateurs de modifier des données, et de rendre ces changements persistants dans la base de données. Même si les jeux de données sont une technologie très efficace, nous vous recommandons d’utiliser Entity Framework Core pour les nouvelles applications .NET. Entity Framework offre un moyen plus naturel d’utiliser des données tabulaires en tant que modèles objet. De plus, il présente une interface de programmation plus simple.

Le jeu de données est une copie en mémoire de données. Si vous modifiez ces données, il est recommandé d’enregistrer ces modifications dans la base de données. Pour ce faire, procédez de trois manières :

  • En appelant l’une des méthodes Update d’un TableAdapter

  • En appelant l’une des méthodes DBDirect du TableAdapter

  • En appelant la méthode UpdateAll sur le TableAdapterManager que Visual Studio génère pour vous lorsque le jeu de données contient des tables liées à d’autres tables du jeu de données

Lorsque vous liez des tables de jeu de données à des contrôles sur une page de formulaire Windows ou XAML, l’architecture de liaison de données effectue tout le travail à votre place.

Si vous êtes familiarisé avec TableAdapters, vous pouvez passer directement à l’une des rubriques suivantes :

Rubrique Description
Insérer de nouveaux enregistrements dans une base de données Comment effectuer des mises à jour et des insertions à l’aide d’objets TableAdapters ou Command
Mettre à jour les données à l’aide d’un TableAdapter Comment effectuer des mises à jour avec TableAdapters
Mise à jour hiérarchique Comment effectuer des mises à jour à partir d’un jeu de données avec au moins deux tables associées
Gérer une exception d’accès concurrentiel Comment gérer les exceptions lorsque deux utilisateurs tentent de modifier les mêmes données dans une base de données en même temps
Guide pratique pour enregistrer des données avec une transaction Comment enregistrer des données dans une transaction à l’aide du système. Espace de noms Transactions et objet TransactionScope
Enregistrer des données dans une transaction Procédure pas à pas qui crée une application Windows Forms pour illustrer l’enregistrement de données dans une base de données à l’intérieur d’une transaction
Enregistrer des données dans une base de données (plusieurs tables) Comment modifier des enregistrements et enregistrer les modifications dans plusieurs tables dans la base de données
Enregistrer les données d’un objet dans une base de données Comment passer des données d’un objet qui ne se trouve pas dans un jeu de données à une base de données à l’aide d’une méthode DbDirect TableAdapter
Enregistrer des données avec les méthodes DBDirect du TableAdapter Comment utiliser TableAdapter pour envoyer des requêtes SQL directement à la base de données
Enregistrer un dataset au format XML Comment enregistrer un jeu de données dans un document XML

Mises à jour en deux étapes

La mise à jour d’une source de données est un processus en deux étapes. La première étape consiste à mettre à jour le jeu de données avec de nouveaux enregistrements, des enregistrements modifiés ou des enregistrements supprimés. Si votre application ne renvoie jamais ces modifications à la source de données, vous avez terminé la mise à jour.

Si vous renvoyez les modifications à la base de données, une deuxième étape est nécessaire. Si vous n’utilisez pas de contrôles liés aux données, vous devez appeler manuellement la méthode Update du même TableAdapter (ou adaptateur de données) que vous avez utilisé pour remplir le jeu de données. Toutefois, vous pouvez également utiliser différents adaptateurs, par exemple, pour déplacer des données d’une source de données vers une autre ou pour mettre à jour plusieurs sources de données. Si vous n’utilisez pas de liaison de données et que vous enregistrez les modifications pour les tables associées, vous devez instancier manuellement une variable de la classe générée TableAdapterManager automatiquement, puis appeler sa méthode UpdateAll.

Diagramme conceptuel des mises à jour du jeu de données

Un jeu de données contient des collections de tables, qui contiennent des collections de lignes. Si vous envisagez de mettre à jour une source de données sous-jacente ultérieurement, vous devez utiliser les méthodes sur la propriété DataTable.DataRowCollection lors de l’ajout ou de la suppression de lignes. Ces méthodes effectuent le suivi des modifications nécessaire à la mise à jour de la source de données. Si vous appelez la collection RemoveAt sur la propriété Lignes, la suppression ne sera pas communiquée à la base de données.

Fusionner des jeux de données

Vous pouvez mettre à jour le contenu d’un jeu de données en le fusionnant avec un autre jeu de données. Cela implique de copier le contenu d’un jeu de données source dans le jeu de données appelant (appelé jeu de données cible). Lorsque vous fusionnez des jeux de données, de nouveaux enregistrements dans le jeu de données source sont ajoutés au jeu de données cible. En outre, des colonnes supplémentaires dans le jeu de données source sont ajoutées au jeu de données cible. La fusion de jeux de données est utile lorsque vous avez un jeu de données local et que vous obtenez un deuxième jeu de données à partir d’une autre application. Il est également utile lorsque vous obtenez un deuxième jeu de données à partir d’un composant tel qu’un service web XML, ou lorsque vous devez intégrer des données à partir de plusieurs jeux de données.

Lors de la fusion de jeux de données, vous pouvez passer un argument booléen (preserveChanges) qui indique à la méthode Merge s’il faut conserver les modifications existantes dans le jeu de données cible. Étant donné que les jeux de données conservent plusieurs versions d’enregistrements, il est important de garder à l’esprit que plusieurs versions des enregistrements sont fusionnées. Le tableau suivant montre comment un enregistrement dans deux jeux de données est fusionné :

DataRowVersion Jeu de données cible Jeu de données source
Original James Wilson James C. Wilson
Actuel Jim Wilson James C. Wilson

L’appel de la méthode Merge sur la table précédente avec les résultats preserveChanges=false targetDataset.Merge(sourceDataset) dans les données suivantes :

DataRowVersion Jeu de données cible Jeu de données source
Original James C. Wilson James C. Wilson
Actuel James C. Wilson James C. Wilson

L’appel de la méthode Merge avec les résultats preserveChanges = true targetDataset.Merge(sourceDataset, true) dans les données suivantes :

DataRowVersion Jeu de données cible Jeu de données source
Original James C. Wilson James C. Wilson
Actuel Jim Wilson James C. Wilson

Attention

Dans le scénario preserveChanges = true, si la méthode RejectChanges est appelée sur un enregistrement dans le jeu de données cible, elle rétablit les données d’origine du jeu de données source. Cela signifie que si vous essayez de mettre à jour la source de données d’origine avec le jeu de données cible, il peut ne pas être en mesure de trouver la ligne d’origine à mettre à jour. Vous pouvez empêcher une violation d’accès concurrentiel en remplissant un autre jeu de données avec les enregistrements mis à jour à partir de la source de données, puis en effectuant une fusion pour empêcher une violation d’accès concurrentiel. (Une violation d’accès concurrentiel se produit lorsqu’un autre utilisateur modifie un enregistrement dans la source de données une fois le jeu de données rempli.)

Mettre à jour des contraintes

Pour apporter des modifications à une ligne de données existante, ajoutez ou mettez à jour des données dans les colonnes individuelles. Si le jeu de données contient des contraintes (telles que des clés étrangères ou des contraintes non nulles), il est possible que l’enregistrement se trouve temporairement dans un état d’erreur lorsque vous le mettez à jour. Autrement dit, elle peut être dans un état d’erreur une fois que vous avez terminé la mise à jour d’une colonne, mais avant de passer à la suivante.

Pour éviter les violations de contraintes prématurées, vous pouvez suspendre temporairement les contraintes de mise à jour. Cela a deux objectifs :

  • Il empêche la levée d’une erreur une fois que vous avez terminé la mise à jour d’une colonne, mais que vous n’avez pas commencé à mettre à jour une autre.

  • Il empêche certains événements de mise à jour d’être déclenchés (événements qui sont souvent utilisés pour la validation).

Notes

Dans Windows Forms, l’architecture de liaison de données intégrée au réseau de données interrompt la vérification des contraintes jusqu’à ce que le focus sorte d’une ligne, et vous n’avez pas besoin d’appeler explicitement les méthodes BeginEdit, EndEditou CancelEdit.

Les contraintes sont automatiquement désactivées lorsque la méthode Merge est appelée sur un jeu de données. Une fois la fusion terminée, s’il existe des contraintes sur le jeu de données qui ne peuvent pas être activées, une ConstraintException est levée. Dans ce cas, la propriété EnforceConstraints est définie sur false, et toutes les violations de contrainte doivent être résolues avant de réinitialiser la propriété EnforceConstraints sur true.

Après avoir terminé une mise à jour, vous pouvez réactiver la vérification des contraintes, qui réactive également les événements de mise à jour et les déclenche.

Pour plus d’informations sur la suspension des événements, consultez Désactiver les contraintes lors du remplissage d’un jeu de données.

Erreurs de mise à jour du jeu de données

Lorsque vous mettez à jour un enregistrement dans un jeu de données, une erreur est possible. Par exemple, vous pouvez écrire par inadvertance des données du mauvais type dans une colonne, ou des données trop longues ou des données qui présentent un autre problème d’intégrité. Vous pouvez également avoir des vérifications de validation spécifiques à l’application qui peuvent déclencher des erreurs personnalisées à n’importe quelle étape d’un événement de mise à jour. Pour plus d’informations, consultez Valider des données dans des jeux de données.

Tenir à jour les informations sur les modifications

Les informations sur les modifications d’un jeu de données sont conservées de deux manières : en signalant les lignes qui indiquent qu’elles ont changé (RowState) et en conservant plusieurs copies d’un enregistrement (DataRowVersion). En utilisant ces informations, les processus peuvent déterminer ce qui a changé dans le jeu de données et envoyer les mises à jour appropriées à la source de données.

RowState, propriété

La propriété RowState d’un objet DataRow est une valeur qui fournit des informations sur l’état d’une ligne de données particulière.

Le tableau suivant détaille les valeurs possibles de l’énumération DataRowState :

DataRowState, valeur Description
Added La ligne a été ajoutée en tant qu’élément à un DataRowCollection. (Une ligne dans cet état n’a pas de version d’origine correspondante, car elle n’existait pas lorsque la dernière méthode AcceptChanges a été appelée).
Deleted La ligne a été supprimée à l'aide de l’objet Delete de DataRow.
Detached La ligne a été créée, mais n'appartient à aucun DataRowCollection. Un DataRow objet est dans cet état immédiatement après sa création et avant son ajout à une collection, et après sa suppression d'une collection.
Modified Une valeur de colonne dans la ligne a changé d’une manière ou d’une autre.
Unchanged La ligne n'a pas été modifiée depuis le dernier appel à AcceptChanges.

DataRowVersion (énumération)

Les jeux de données conservent plusieurs versions d’enregistrements. Les champs DataRowVersion sont utilisés lors de la récupération de la valeur trouvée dans un DataRow à l’aide de la propriété Item[] ou de la méthode GetChildRows de l’objet DataRow.

Le tableau suivant détaille les valeurs possibles de l’énumération DataRowVersion :

Valeur DataRowVersion Description
Current La version actuelle d’un enregistrement contient toutes les modifications qui ont été effectuées sur l’enregistrement depuis la dernière fois que AcceptChanges a été appelé. Si la ligne a été supprimée, il n’existe aucune version actuelle.
Default Valeur par défaut d’un enregistrement, telle que définie par le schéma ou la source de données du jeu de données.
Original La version d’origine d’un enregistrement est une copie de l’enregistrement, car il s’agissait de la dernière fois que les modifications ont été validées dans le jeu de données. Dans la pratique, il s’agit généralement de la version d’un enregistrement lu à partir d’une source de données.
Proposed Version proposée d’un enregistrement disponible temporairement pendant que vous êtes au milieu d’une mise à jour, c’est-à-dire entre le moment où vous avez appelé la méthode BeginEdit et la méthode EndEdit. Vous accédez généralement à la version proposée d’un enregistrement dans un gestionnaire pour un événement tel que RowChanging. L’appel de la méthode CancelEdit inverse les modifications et supprime la version proposée de la ligne de données.

Les versions d’origine et actuelles sont utiles lorsque les informations de mise à jour sont transmises à une source de données. En règle générale, lorsqu’une mise à jour est envoyée à la source de données, les nouvelles informations relatives à la base de données se situent dans la version actuelle d’un enregistrement. Les informations de la version d’origine sont utilisées pour localiser l’enregistrement à mettre à jour.

Par exemple, dans un cas où la clé primaire d’un enregistrement est modifiée, vous avez besoin d’un moyen de localiser l’enregistrement correct dans la source de données afin de mettre à jour les modifications. Si aucune version d’origine n’existait, l’enregistrement serait probablement ajouté à la source de données, ce qui entraînerait non seulement un enregistrement indésirable supplémentaire, mais aussi un enregistrement incorrect et obsolète. Les deux versions sont également utilisées dans le contrôle d’accès concurrentiel. Vous pouvez comparer la version d'origine à un enregistrement dans la source de données pour déterminer si l'enregistrement a changé depuis son chargement dans le jeu de données.

La version proposée est utile lorsque vous devez effectuer une validation avant de valider les modifications apportées au jeu de données.

Même si les enregistrements ont changé, il n’existe pas toujours de versions d’origine ou actuelles de cette ligne. Lorsque vous insérez une nouvelle ligne dans la table, il n’existe aucune version d’origine, uniquement une version actuelle. De même, si vous supprimez une ligne en appelant la méthode Delete de la table, il existe une version d’origine, mais aucune version actuelle.

Vous pouvez tester pour voir si une version spécifique d'un enregistrement existe en interrogeant la méthode HasVersion d'une ligne de données. Vous pouvez accéder à l’une ou l’autre version d’un enregistrement en passant une valeur DataRowVersion d’énumération comme argument facultatif lorsque vous demandez la valeur d’une colonne.

Obtenir les enregistrements modifiés

Il est courant de ne pas mettre à jour chaque enregistrement d’un jeu de données. Par exemple, un utilisateur peut utiliser un contrôle DataGridView de Windows Forms qui affiche de nombreux enregistrements. Toutefois, l’utilisateur ne peut mettre à jour que quelques enregistrements, en supprimer un et en insérer un nouveau. Les jeux de données et les tables de données fournissent une méthode (GetChanges) pour renvoyer uniquement les lignes qui ont été modifiées.

Vous pouvez créer des sous-ensembles d’enregistrements modifiés à l’aide de la méthode GetChanges de la table de données (GetChanges) ou du jeu de données (GetChanges) lui-même. Si vous appelez la méthode pour la table de données, elle retourne une copie de la table avec uniquement les enregistrements modifiés. De même, si vous appelez la méthode sur le jeu de données, vous obtenez un nouveau jeu de données avec uniquement des enregistrements modifiés.

GetChanges retourne tous les enregistrements modifiés. En revanche, en passant le DataRowState souhaité en tant que paramètre à la méthode GetChanges, vous pouvez spécifier le sous-ensemble d’enregistrements modifiés souhaité : enregistrements nouvellement ajoutés, enregistrements marqués pour suppression, enregistrements détachés ou enregistrements modifiés.

L’obtention d’un sous-ensemble d’enregistrements modifiés est utile lorsque vous souhaitez envoyer des enregistrements à un autre composant à des fins de traitement. Au lieu d’envoyer l’ensemble du jeu de données, vous pouvez réduire la surcharge liée à la communication avec l’autre composant en obtenant uniquement les enregistrements dont le composant a besoin.

Valider les modifications dans le jeu de données

Lorsque des modifications sont apportées au jeu de données, la propriété RowState des lignes modifiées est définie. Les versions d’origine et actuelles des enregistrements sont établies, conservées et mises à votre disposition par la propriété RowVersion. Les métadonnées stockées dans les propriétés de ces lignes modifiées sont nécessaires pour envoyer les mises à jour correctes à la source de données.

Si les modifications reflètent l’état actuel de la source de données, vous n’avez plus besoin de conserver ces informations. En règle générale, le jeu de données et sa source sont synchronisés à deux reprises :

  • Immédiatement après avoir chargé des informations dans le jeu de données, par exemple lorsque vous lisez des données à partir de la source.

  • Après avoir envoyé les modifications du jeu de données à la source de données (mais pas avant, car vous perdriez les informations de modification requises pour envoyer les modifications à la base de données).

Vous pouvez valider les modifications en attente dans le jeu de données en appelant la méthode AcceptChanges. En règle générale, AcceptChanges est appelé aux moments suivants :

  • Après avoir chargé le jeu de données. Si vous chargez un jeu de données en appelant la méthode Fill d’un TableAdapter, l’adaptateur valide automatiquement les modifications pour vous. Toutefois, si vous chargez un jeu de données en fusionnant un autre jeu de données, vous devez valider les modifications manuellement.

    Notes

    Vous pouvez empêcher l’adaptateur de valider automatiquement les modifications lorsque vous appelez la méthode Fill en définissant la propriété AcceptChangesDuringFill de l’adaptateur sur false. S’il a la valeur false, le RowState de chaque ligne insérée pendant le remplissage est défini sur Added.

  • Après avoir envoyé des modifications de jeu de données à un autre processus, tel qu’un service web XML.

    Attention

    La validation de la modification de cette façon efface toutes les informations de modification. Ne commitez pas les modifications tant qu’une fois que vous avez terminé d’effectuer des opérations qui nécessitent que votre application sache quelles modifications ont été apportées dans le jeu de données.

Cette méthode effectue les opérations suivantes :

  • Écrit la version Current d’un enregistrement dans sa version Original et remplace la version d’origine.

  • Supprime toute ligne dans laquelle la propriété RowState a la valeur Deleted.

  • Définit la propriété RowState d’un enregistrement sur Unchanged.

La méthode AcceptChanges est disponible à trois niveaux. Vous pouvez l’appeler sur un objet DataRow pour valider les modifications pour cette ligne. Vous pouvez également l’appeler sur un objet DataTable pour valider toutes les lignes d’une table. Enfin, vous pouvez l’appeler sur l’objet DataSet pour valider toutes les modifications en attente dans tous les enregistrements de toutes les tables du jeu de données.

Le tableau suivant décrit les modifications validées en fonction de l’objet sur lequel la méthode est appelée :

Méthode Résultats
System.Data.DataRow.AcceptChanges Les modifications sont validées uniquement sur la ligne spécifique.
System.Data.DataTable.AcceptChanges Les modifications sont validées sur toutes les lignes de la table spécifique.
System.Data.DataSet.AcceptChanges Les modifications sont validées sur toutes les lignes de toutes les tables du jeu de données.

Notes

Si vous chargez un jeu de données en appelant la méthode Fill d’un TableAdapter, vous n’avez pas besoin d’accepter explicitement les modifications. Par défaut, la méthode Fill appelle la méthode AcceptChanges une fois qu’elle a fini de remplir la table de données.

Une méthode associée, RejectChanges, annule l’effet des modifications en copiant la version Original dans la version Current des enregistrements. Il définit également le RowState de chaque enregistrement sur Unchanged.

Validation des données

Pour vérifier que les données de votre application répondent aux exigences des processus auxquels elles sont transmises, vous devez souvent ajouter une validation. Cela peut impliquer la vérification de l’exactitude de l’entrée d’un utilisateur dans un formulaire, la validation des données envoyées à votre application par une autre application ou même la vérification que les informations calculées dans votre composant répondent aux contraintes de votre source de données et des exigences de votre application.

Vous pouvez valider les données de plusieurs manières :

  • Dans la couche métier, en ajoutant du code à votre application pour valider les données. Le jeu de données est un endroit où vous pouvez effectuer cette opération. Le jeu de données offre certains des avantages de la validation back-end, comme la possibilité de valider les modifications à mesure que les valeurs de colonne et de ligne changent. Pour plus d’informations, consultez Valider des données dans des jeux de données.

  • Dans la couche de présentation, en ajoutant la validation aux formulaires. Pour plus d’informations, consultez Validation d’entrée d’utilisateur dans Windows Forms.

  • Dans le back-end de données, en envoyant des données à la source de données (par exemple, la base de données) et en lui permettant d’accepter ou de rejeter les données. Si vous travaillez avec une base de données qui dispose d’installations sophistiquées pour valider les données et fournir des informations d’erreur, cela peut être une approche pratique, car vous pouvez valider les données, quel que soit l’endroit d’où elles proviennent. Toutefois, cette approche peut ne pas prendre en charge les exigences de validation spécifiques à l’application. En outre, le fait que la source de données valide les données peut entraîner de nombreux allers-retours vers la source de données, selon la façon dont votre application facilite la résolution des erreurs de validation générées par le serveur principal.

    Important

    Lorsque vous utilisez des commandes de données avec une propriété CommandType définie sur Text, vérifiez soigneusement les informations envoyées à partir d’un client avant de les transmettre à votre base de données. Des utilisateurs malveillants peuvent tenter d’envoyer (injecter) des instructions SQL modifiées ou supplémentaires afin d’accéder à la base de données ou de l’endommager. Avant de transférer l’entrée utilisateur vers une base de données, vérifiez toujours que les informations sont valides. Une bonne pratique consiste à toujours utiliser des requêtes paramétrables ou des procédures stockées lorsque cela est possible.

Transmettre des mises à jour à la source de données

Une fois que des modifications ont été apportées dans un jeu de données, vous pouvez transmettre les modifications à une source de données. Le plus souvent, vous appelez la méthode Update d’un TableAdapter (ou adaptateur de données). La méthode effectue une boucle dans chaque enregistrement d’une table de données, détermine le type de mise à jour requis (mise à jour, insertion ou suppression), le cas échéant, puis exécute la commande appropriée.

Pour illustrer la façon dont les mises à jour sont effectuées, supposons que votre application utilise un jeu de données qui contient une table de données unique. L’application extrait deux lignes de la base de données. Après la récupération, la table de données en mémoire ressemble à ceci :

(RowState)     CustomerID   Name             Status
(Unchanged)    c200         Robert Lyon      Good
(Unchanged)    c400         Nancy Buchanan    Pending

Votre application change l’état de Nancy Buchanan en « Préféré ». À la suite de cette modification, la valeur de la propriété RowState de cette ligne passe de Unchanged à Modified. La valeur de la propriété RowState de la première ligne reste Unchanged. La table de données se présente maintenant comme ceci :

(RowState)     CustomerID   Name             Status
(Unchanged)    c200         Robert Lyon      Good
(Modified)     c400         Nancy Buchanan    Preferred

Votre application appelle maintenant la méthode Update pour transmettre le jeu de données à la base de données. La méthode inspecte chaque ligne à son tour. Pour la première ligne, la méthode ne transmet aucune instruction SQL à la base de données, car cette ligne n’a pas changé depuis qu’elle a été extraite à l’origine de la base de données.

Toutefois, pour la deuxième ligne, la méthode Update appelle automatiquement la commande de données correcte et la transmet à la base de données. La syntaxe spécifique de l’instruction SQL dépend du dialecte de SQL pris en charge par le magasin de données sous-jacent. Toutefois, les caractéristiques générales suivantes de l’instruction SQL transmise sont notables :

  • L’instruction SQL transmise est une instruction UPDATE. L’adaptateur sait utiliser une instruction UPDATE, car la valeur de la propriété RowState est Modified.

  • L’instruction SQL transmise inclut une clause WHERE indiquant que la cible de l’instruction UPDATE est la ligne où CustomerID = 'c400'. Cette partie de l’instruction SELECT distingue la ligne cible de toutes les autres, car la CustomerID est la clé primaire de la table cible. Les informations de la clause WHERE sont dérivées de la version d’origine de l’enregistrement (DataRowVersion.Original), au cas où les valeurs requises pour identifier la ligne ont changé.

  • L’instruction SQL transmise inclut la clause SET pour définir les nouvelles valeurs des colonnes modifiées.

    Remarque

    Si la propriété UpdateCommand de TableAdapter a été définie sur le nom d’une procédure stockée, l’adaptateur ne construit pas d’instruction SQL. Au lieu de cela, il appelle la procédure stockée avec les paramètres appropriés transmis.

Transmettre des paramètres

Vous utilisez généralement des paramètres pour passer les valeurs des enregistrements qui vont être mis à jour dans la base de données. Quand la méthode Update de TableAdapter exécute une instruction UPDATE, elle doit renseigner les valeurs des paramètres. Il obtient ces valeurs de la collection Parameters pour la commande de données appropriée , dans ce cas, l’objet UpdateCommand dans TableAdapter.

Si vous avez utilisé les outils Visual Studio pour générer un adaptateur de données, l’objet UpdateCommand contient une collection de paramètres qui correspondent à chaque espace réservé de paramètre dans l’instruction.

La propriété System.Data.SqlClient.SqlParameter.SourceColumn de chaque paramètre pointe vers une colonne dans la table de données. Par exemple, la propriété SourceColumn des paramètres au_id et Original_au_id est définie sur n’importe quelle colonne de la table de données contenant l’ID d’auteur. Lorsque la méthode Update de l’adaptateur s’exécute, elle lit la colonne d’id d’auteur à partir de l’enregistrement en cours de mise à jour et remplit les valeurs dans l’instruction.

Dans une instruction UPDATE, vous devez spécifier à la fois les nouvelles valeurs (celles qui seront écrites dans l’enregistrement) ainsi que les anciennes valeurs (pour que l’enregistrement puisse se trouver dans la base de données). Il existe donc deux paramètres pour chaque valeur : une pour la clause SET et un autre pour la clause WHERE. Les deux paramètres lisent les données de l’enregistrement en cours de mise à jour, mais ils obtiennent différentes versions de la valeur de colonne en fonction de la propriété du paramètre SourceVersion. Le paramètre de la clause SET obtient la version actuelle et celui de la clause WHERE obtient la version d’origine.

Remarque

Vous pouvez également définir vous-même des valeurs dans la collection Parameters dans du code, ce que vous feriez généralement dans un gestionnaire d’événements pour l’événement RowChanging de l’adaptateur de données.

Contenu connexe