Enregistrer des données dans la base de données dans les applications .NET Framework

Le jeu de données est une copie en mémoire des 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 Update des méthodes d’un TableAdapter

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

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

Lorsque vous liez des tables de jeu de données à des contrôles sur un formulaire Windows Form ou une page XAML, le système de liaison de données effectue tout le travail pour vous.

Si vous connaissez TableAdapters, vous pouvez accéder directement à l’une des rubriques suivantes :

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 n’envoie 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 requise. Si vous n’utilisez pas de contrôles liés aux données, vous devez appeler manuellement la Update méthode 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 mettre à jour plusieurs sources de données. Si vous n’utilisez pas de liaison de données et que vous enregistrez des modifications pour les tables associées, vous devez instancier manuellement une variable de la classe générée automatiquement TableAdapterManager , puis appeler sa UpdateAll méthode.

Un jeu de données contient des collections de tables, qui contiennent des collections de lignes. Si vous envisagez de mettre à jour ultérieurement une source de données sous-jacente, 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 pour mettre à jour la source de données. Si vous appelez la collection RemoveAt de la propriété Rows, 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 la copie du 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 Merge méthode 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é :

Appeler la méthode Merge sur la table précédente avec preserveChanges=false targetDataset.Merge(sourceDataset) produit les données suivantes :

L'appel de la méthode Merge en utilisant preserveChanges = true targetDataset.Merge(sourceDataset, true) entraîne les données suivantes :

Contraintes de mise à jour

Pour apporter des modifications à une ligne de données existante, ajouter ou mettre à 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 nullables), il est possible que l’enregistrement puisse temporairement être dans un état d’erreur lorsque vous le mettez à jour. Autrement dit, il 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 sert à deux fins :

• Elle 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 démarré la mise à jour d’une autre.

• Cela empêche la levée de certains événements de mise à jour (événements souvent utilisés pour la validation).

Les contraintes sont automatiquement désactivées lorsque la Merge méthode 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 déclenchée. Dans ce cas, la propriété EnforceConstraints est définie à false, et toutes les violations de contrainte doivent être résolues avant de réinitialiser la propriété EnforceConstraints à true.

Une fois la mise à jour terminée, vous pouvez réactiver la vérification des contraintes, qui réenable é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, il existe la possibilité d’une erreur. Par exemple, vous pouvez écrire par inadvertance des données du type incorrect 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 pendant n’importe quelle étape d’un événement de mise à jour. Pour plus d’informations, consultez Valider les données dans les jeux de données.

Conserver des informations sur les modifications

Les informations sur les modifications apportées à un jeu de données sont conservées de deux façons : 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 RowState propriété d’un DataRow objet 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 :

DataRowVersion (énumération)

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

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

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 de 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 dans un enregistrement qui est 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 la validation avant de valider réellement les modifications apportées au jeu de données.

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

Vous pouvez tester si une version spécifique d’un enregistrement existe en interrogeant la méthode d’une ligne de HasVersion données. Vous pouvez accéder à l’une ou l’autre version d’un enregistrement en passant une DataRowVersion valeur d’énumération en tant qu’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 dans un jeu de données. Par exemple, un utilisateur peut utiliser un contrôle Windows Forms DataGridView qui affiche de nombreux enregistrements. Toutefois, l’utilisateur peut mettre à jour seulement 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 GetChanges méthode 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 par lui-même retourne tous les enregistrements modifiés. En revanche, en passant le paramètre souhaité DataRowState à la GetChanges méthode, vous pouvez spécifier le sous-ensemble d’enregistrements modifiés souhaités : 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 pour le traitement. Au lieu d’envoyer l’intégralité du jeu de données, vous pouvez réduire la surcharge de communication avec l’autre composant en obtenant uniquement les enregistrements dont le composant a besoin.

Valider les modifications dans le jeu de données

À mesure que des modifications sont apportées dans le jeu de données, la RowState propriété 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 RowVersion propriété. 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, il existe deux fois lorsque le jeu de données et sa source sont synchronisés :

• 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é des modifications du jeu de données à la source de données (mais pas avant, car vous perdez les informations de modification requises pour envoyer des modifications à la base de données).

Vous pouvez valider les modifications en attente dans le jeu de données en appelant la AcceptChanges méthode. 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 d’une Fill 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 manuellement les modifications.

  Remarque

  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 est défini sur false, alors la RowState de chaque ligne insérée pendant le remplissage est définie sur Added.

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

  Avertissement

  La validation de la modification de cette façon efface toutes les informations de modification. Ne validez pas les modifications tant que vous n’avez pas terminé d’effectuer des opérations nécessitant 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 Current version d’un enregistrement dans sa Original version et remplace ainsi la version d’origine.

• Supprime toute ligne où la propriété RowState est définie sur Deleted.

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

La AcceptChanges méthode est disponible à trois niveaux. Vous pouvez l’appeler sur un DataRow objet pour valider les modifications pour cette ligne uniquement. Vous pouvez également l’appeler sur un DataTable objet 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 :

Une méthode associée, RejectChangesannule l’effet des modifications en copiant la Original version dans la Current version 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 elle est passée, vous devez souvent ajouter la validation. Cela peut impliquer la vérification que l’entrée d’un utilisateur dans un formulaire est correcte, en validant les données envoyées à votre application par une autre application, ou même en vérifiant que les informations calculées au sein de votre composant se trouvent dans les contraintes de votre source de données et de vos exigences d’application.

Vous pouvez valider les données de plusieurs façons :

• 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 faire cela. Le jeu de données offre certains des avantages de la validation back-end, comme la possibilité de valider les modifications alors que les valeurs de colonne et de ligne changent. Pour plus d’informations, consultez Valider les données dans les jeux de données.

• Dans la couche de présentation, en ajoutant la validation aux formulaires. Pour plus d’informations, consultez validation des entrées 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 quelle que soit leur provenance. Toutefois, cette approche peut ne pas prendre en charge les exigences de validation spécifiques à l’application. De plus, 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 manière dont votre application facilite la résolution des erreurs de validation générées par le back-end.

  Importante

  Lorsque vous utilisez des commandes de données, avec une propriété CommandType définie sur Text, vérifiez attentivement les informations envoyées à partir d’un client avant de les transmettre à votre base de données. Les utilisateurs malveillants peuvent essayer d’envoyer (injecter) des instructions SQL modifiées ou supplémentaires dans le but d’obtenir un accès non autorisé ou de endommager la base de données. Avant de transférer l’entrée utilisateur vers une base de données, vérifiez toujours que les informations sont valides. Il est recommandé d’utiliser toujours 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 les modifications apportées dans un jeu de données, vous pouvez transmettre les modifications à une source de données. Le plus souvent, vous effectuez cette opération en appelant la Update méthode 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.

Comme illustration de la façon dont les mises à jour sont effectuées, supposons que votre application utilise un jeu de données qui contient une seule table de données. 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 remplace l’état de Nancy Buchanan par « Préféré ». En conséquence de cette modification, la valeur de la RowState propriété pour cette ligne passe de UnchangedModified. La valeur de la propriété pour la RowState première ligne reste Unchanged. La table de données ressemble maintenant à ceci :

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

Votre application appelle maintenant la Update méthode 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 Update méthode 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 remarquables :

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

• L’instruction SQL transmise inclut une WHERE clause 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 elle CustomerID est la clé primaire de la table cible. Les informations relatives à la WHERE clause 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 SET clause, pour définir les nouvelles valeurs des colonnes modifiées.

  Remarque

  Si la propriété de UpdateCommand 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 en passant les paramètres appropriés.

Passer des paramètres

Vous utilisez généralement des paramètres pour transmettre les valeurs des enregistrements qui vont être mis à jour dans la base de données. Lorsque la méthode de Update TableAdapter exécute une UPDATE instruction, elle doit renseigner les valeurs de paramètre. Elle obtient ces valeurs de la Parameters collection 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 l'instruction.

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

Dans une UPDATE instruction, vous devez spécifier les nouvelles valeurs (celles qui seront écrites dans l’enregistrement) ainsi que les anciennes valeurs (afin que l’enregistrement puisse se trouver dans la base de données). Il existe donc deux paramètres pour chaque valeur : un pour la SET clause et un autre pour la WHERE clause. 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 SourceVersion paramètre. Le paramètre de la SET clause obtient la version actuelle et le paramètre de la WHERE clause obtient la version d’origine.

Contenu connexe

• Outils de gestion de données dans Visual Studio
• Créer et configurer TableAdapters
• Mettre à jour des données à l’aide d’un TableAdapter
• lier des contrôles aux données dans Visual Studio
• Valider les données
• Guide pratique pour ajouter, modifier et supprimer des entités (services de données WCF)