Utilisation de procédures stockées existantes pour les TableAdapters de dataset typé (C#)

par Scott Mitchell

Télécharger le PDF

Dans le tutoriel précédent, nous avons appris à utiliser l’Assistant TableAdapter pour générer de nouvelles procédures stockées. Dans ce tutoriel, nous apprenons comment le même Assistant TableAdapter peut fonctionner avec des procédures stockées existantes. Nous apprenons également à ajouter manuellement de nouvelles procédures stockées à notre base de données.

Présentation

Dans le tutoriel précédent, nous avons vu comment les TableAdapters de Typed DataSet peuvent être configurés pour utiliser des procédures stockées pour accéder aux données plutôt que pour les instructions SQL ad hoc. En particulier, nous avons examiné comment l’Assistant TableAdapter crée automatiquement ces procédures stockées. Lors du portage d’une application héritée vers ASP.NET 2.0 ou lors de la création d’un site web ASP.NET 2.0 autour d’un modèle de données existant, les chances sont que la base de données contient déjà les procédures stockées dont nous avons besoin. Vous pouvez également préférer créer vos procédures stockées manuellement ou via un autre outil que l’Assistant TableAdapter qui génère automatiquement vos procédures stockées.

Dans ce tutoriel, nous allons examiner comment configurer TableAdapter pour utiliser des procédures stockées existantes. Étant donné que la base de données Northwind comporte uniquement un petit ensemble de procédures stockées intégrées, nous allons également examiner les étapes nécessaires pour ajouter manuellement de nouvelles procédures stockées à la base de données via l’environnement Visual Studio. Commençons !

Remarque

Dans le didacticiel sur la création de package de restrictions de base de données dans un didacticiel sur les transactions, nous avons ajouté des méthodes à TableAdapter pour prendre en charge les transactions (BeginTransactionCommitTransactionet ainsi de suite). Vous pouvez également gérer entièrement les transactions dans une procédure stockée, ce qui ne nécessite aucune modification du code de couche d’accès aux données. Dans ce tutoriel, nous allons explorer les commandes T-SQL utilisées pour exécuter des instructions de procédure stockée dans l’étendue d’une transaction.

Étape 1 : Ajout de procédures stockées à la base de données Northwind

Visual Studio facilite l’ajout de nouvelles procédures stockées à une base de données. Ajoutons une nouvelle procédure stockée à la base de données Northwind qui retourne toutes les colonnes de la Products table pour celles qui ont une valeur particulière CategoryID . Dans la fenêtre Explorateur de serveurs, développez la base de données Northwind afin que ses dossiers ( Diagrammes de base de données, Tables, Vues, etc.) soient affichés. Comme nous l’avons vu dans le tutoriel précédent, le dossier Procédures stockées contient les procédures stockées existantes de la base de données. Pour ajouter une nouvelle procédure stockée, cliquez simplement avec le bouton droit sur le dossier Procédures stockées et choisissez l’option Ajouter une nouvelle procédure stockée dans le menu contextuel.

Figure 1 : Cliquez avec le bouton droit sur le dossier Procédures stockées et ajoutez une nouvelle procédure stockée (cliquez pour afficher l’image de taille complète)

Comme le montre la figure 1, la sélection de l’option Ajouter une nouvelle procédure stockée ouvre une fenêtre de script dans Visual Studio avec le plan du script SQL nécessaire pour créer la procédure stockée. C’est notre travail pour développer ce script et l’exécuter, à quel moment la procédure stockée sera ajoutée à la base de données.

Entrez le script suivant :

CREATE PROCEDURE dbo.Products_SelectByCategoryID 
(
    @CategoryID int
)
AS
SELECT ProductID, ProductName, SupplierID, CategoryID, 
       QuantityPerUnit, UnitPrice, UnitsInStock, UnitsOnOrder, 
       ReorderLevel, Discontinued
FROM Products
WHERE CategoryID = @CategoryID

Ce script, lorsqu’il est exécuté, ajoute une nouvelle procédure stockée à la base de données Northwind nommée Products_SelectByCategoryID. Cette procédure stockée accepte un paramètre d’entrée unique (@CategoryIDde type int) et retourne tous les champs de ces produits avec une valeur correspondante CategoryID .

Pour exécuter ce CREATE PROCEDURE script et ajouter la procédure stockée à la base de données, cliquez sur l’icône Enregistrer dans la barre d’outils ou appuyez sur Ctrl+S. Après cela, le dossier Procédures stockées s’actualise, affichant la procédure stockée nouvellement créée. En outre, le script dans la fenêtre changera de subtilité à CREATE PROCEDURE dbo.Products_SelectProductByCategoryIDALTER PROCEDUREdbo.Products_SelectProductByCategoryID. CREATE PROCEDURE ajoute une nouvelle procédure stockée à la base de données, tandis que met ALTER PROCEDURE à jour une procédure existante. Depuis le début du script, ALTER PROCEDUREla modification des paramètres d’entrée des procédures stockées ou des instructions SQL et le fait de cliquer sur l’icône Enregistrer met à jour la procédure stockée avec ces modifications.

La figure 2 montre Visual Studio après l’enregistrement de la Products_SelectByCategoryID procédure stockée.

Figure 2 : La procédure Products_SelectByCategoryID stockée a été ajoutée à la base de données (cliquez pour afficher l’image de taille complète)

Étape 2 : Configuration de TableAdapter pour utiliser une procédure stockée existante

Maintenant que la Products_SelectByCategoryID procédure stockée a été ajoutée à la base de données, nous pouvons configurer notre couche d’accès aux données pour utiliser cette procédure stockée lorsqu’une de ses méthodes est appelée. En particulier, nous allons ajouter une GetProductsByCategoryID(categoryID) méthode au ProductsTableAdapter jeu NorthwindWithSprocs de données typé qui appelle la Products_SelectByCategoryID procédure stockée que nous venons de créer.

Commencez par ouvrir le NorthwindWithSprocs DataSet. Cliquez avec le bouton droit sur l’Assistant ProductsTableAdapter Ajouter une requête pour lancer l’Assistant Configuration des requêtes TableAdapter. Dans le tutoriel précédent, nous avons choisi d’avoir TableAdapter créer une procédure stockée pour nous. Toutefois, pour ce tutoriel, nous voulons connecter la nouvelle méthode TableAdapter à la procédure stockée existante Products_SelectByCategoryID . Par conséquent, choisissez l’option Utiliser la procédure stockée existante à partir de la première étape de l’Assistant, puis cliquez sur Suivant.

Figure 3 : Choisir l’option Utiliser la procédure stockée existante (cliquez pour afficher l’image de taille complète)

L’écran suivant fournit une liste déroulante remplie avec les procédures stockées de la base de données. La sélection d’une procédure stockée répertorie ses paramètres d’entrée à gauche et les champs de données retournés (le cas échéant) à droite. Choisissez la Products_SelectByCategoryID procédure stockée dans la liste, puis cliquez sur Suivant.

Figure 4 : Sélectionner la procédure stockée (cliquez pour afficher l’image Products_SelectByCategoryIDde taille complète)

L’écran suivant nous demande quel type de données est retourné par la procédure stockée et notre réponse ici détermine le type retourné par la méthode TableAdapter. Par exemple, si nous indiquons que les données tabulaires sont retournées, la méthode retourne une ProductsDataTable instance remplie avec les enregistrements retournés par la procédure stockée. En revanche, si nous indiquons que cette procédure stockée retourne une valeur unique, TableAdapter retourne une object valeur affectée à la valeur dans la première colonne du premier enregistrement retourné par la procédure stockée.

Étant donné que la Products_SelectByCategoryID procédure stockée retourne tous les produits appartenant à une catégorie particulière, choisissez la première réponse - Données tabulaires - puis cliquez sur Suivant.

Figure 5 : Indiquer que la procédure stockée retourne des données tabulaires (cliquez pour afficher l’image de taille complète)

Tout ce qui reste est d’indiquer les modèles de méthode à utiliser suivis des noms de ces méthodes. Laissez à la fois les options Fill a DataTable et Return a DataTable cochées, mais renommez les méthodes vers FillByCategoryID et GetProductsByCategoryID. Cliquez ensuite sur Suivant pour consulter un résumé des tâches que l’Assistant effectuera. Si tout semble correct, cliquez sur Terminer.

Figure 6 : Nommer les méthodes FillByCategoryID et GetProductsByCategoryID (Cliquez pour afficher l’image de taille complète)

Remarque

Les méthodes TableAdapter que nous venons de créer et FillByCategoryIDGetProductsByCategoryID, attendez-vous à un paramètre d’entrée de type int. Cette valeur de paramètre d’entrée est passée dans la procédure stockée via son @CategoryID paramètre. Si vous modifiez les paramètres de la Products_SelectByCategory procédure stockée, vous devez également mettre à jour les paramètres de ces méthodes TableAdapter. Comme indiqué dans le didacticiel précédent, vous pouvez effectuer cette opération de deux manières : en ajoutant ou supprimant manuellement des paramètres de la collection de paramètres ou en réexécutant l’Assistant TableAdapter.

Étape 3 : Ajout d’uneGetProductsByCategoryID(categoryID)méthode à la BLL

Une fois la GetProductsByCategoryID méthode DAL terminée, l’étape suivante consiste à fournir l’accès à cette méthode dans la couche logique métier. Ouvrez le ProductsBLLWithSprocs fichier de classe et ajoutez la méthode suivante :

[System.ComponentModel.DataObjectMethodAttribute
    (System.ComponentModel.DataObjectMethodType.Select, false)]
public NorthwindWithSprocs.ProductsDataTable GetProductByCategoryID(int categoryID)
{
    return Adapter.GetProductsByCategoryID(categoryID);
}

Cette méthode BLL retourne simplement le ProductsDataTable retour de la ProductsTableAdapter méthode s GetProductsByCategoryID . L’attribut DataObjectMethodAttribute fournit des métadonnées utilisées par l’Assistant Configuration de la source de données ObjectDataSource. En particulier, cette méthode apparaît dans la liste déroulante de l’onglet SELECT.

Étape 4 : Affichage des produits par catégorie

Pour tester la procédure stockée nouvellement ajoutée Products_SelectByCategoryID et les méthodes DAL et BLL correspondantes, nous allons créer une page ASP.NET qui contient une liste déroulante et un GridView. La Liste déroulante répertorie toutes les catégories de la base de données, tandis que GridView affiche les produits appartenant à la catégorie sélectionnée.

Remarque

Nous avons créé des interfaces maître/détail à l’aide de DropDownLists dans les didacticiels précédents. Pour une présentation plus approfondie de l’implémentation d’un tel rapport maître/détail, consultez le didacticiel Master/Detail Filtering With a DropDownList .

Ouvrez la ExistingSprocs.aspx page dans le AdvancedDAL dossier et faites glisser une liste déroulante de la boîte à outils vers le Concepteur. Définissez la propriété DropDownList ID sur Categories et sa AutoPostBack propriété truesur . Ensuite, à partir de sa balise active, liez la liste déroulante à un nouvel ObjectDataSource nommé CategoriesDataSource. Configurez ObjectDataSource pour qu’il récupère ses données à partir de la méthode de CategoriesBLL classeGetCategories. Définissez les listes déroulantes dans les onglets UPDATE, INSERT et DELETE sur (Aucun).

Figure 7 : Récupérer des données à partir de la méthode class s CategoriesBLL (Click pour afficher l’image GetCategoriesde taille complète)

Figure 8 : Définir les listes déroulantes dans les onglets UPDATE, INSERT et DELETE sur (Aucun) (Cliquez pour afficher l’image de taille complète)

Une fois l’Assistant ObjectDataSource terminé, configurez la liste déroulante pour afficher le CategoryName champ de données et utiliser le CategoryID champ comme Value correspondant à chacun d’eux ListItem.

À ce stade, le balisage déclaratif dropDownList et ObjectDataSource doit ressembler à ce qui suit :

<asp:DropDownList ID="Categories" runat="server" AutoPostBack="True" 
    DataSourceID="CategoriesDataSource" DataTextField="CategoryName" 
    DataValueField="CategoryID">
</asp:DropDownList>
<asp:ObjectDataSource ID="CategoriesDataSource" runat="server"
    OldValuesParameterFormatString="original_{0}" 
    SelectMethod="GetCategories" TypeName="CategoriesBLL">
</asp:ObjectDataSource>

Ensuite, faites glisser un GridView sur le Concepteur, en le plaçant sous la Liste déroulante. Définissez gridView s ID sur ProductsByCategory et, à partir de sa balise active, liez-le à un nouvel ObjectDataSource nommé ProductsByCategoryDataSource. ProductsByCategoryDataSource Configurez ObjectDataSource pour utiliser la ProductsBLLWithSprocs classe, en la faisant récupérer ses données à l’aide de la GetProductsByCategoryID(categoryID) méthode. Étant donné que ce GridView est utilisé uniquement pour afficher les données, définissez les listes déroulantes dans les onglets UPDATE, INSERT et DELETE sur (Aucun) et cliquez sur Suivant.

Figure 9 : Configurer ObjectDataSource pour utiliser la classe (Cliquez pour afficher l’image ProductsBLLWithSprocsde taille complète)

Figure 10 : Récupérer des données de la méthode (Cliquez pour afficher l’image GetProductsByCategoryID(categoryID)de taille complète)

La méthode choisie dans l’onglet SELECT attend un paramètre. Par conséquent, l’étape finale de l’Assistant nous invite à entrer la source du paramètre. Définissez la liste déroulante Source du paramètre sur Control et choisissez le Categories contrôle dans la liste déroulante ControlID. Cliquez sur Terminer pour terminer l’Assistant.

Figure 11 : Utiliser la Categories liste déroulante comme source du categoryID paramètre (cliquez pour afficher l’image de taille complète)

Une fois l’Assistant ObjectDataSource terminé, Visual Studio ajoute BoundFields et un CheckBoxField pour chacun des champs de données de produit. N’hésitez pas à personnaliser ces champs comme vous le voyez.

Visitez la page via un navigateur. Lorsque vous visitez la page, la catégorie Boissons est sélectionnée et les produits correspondants répertoriés dans la grille. La modification de la liste déroulante en catégorie alternative, comme l’illustre la figure 12, entraîne un postback et recharge la grille avec les produits de la catégorie nouvellement sélectionnée.

Figure 12 : Les produits de la catégorie Produire sont affichés (cliquez pour afficher l’image de taille complète)

Étape 5 : Habillage d’instructions de procédure stockée dans l’étendue d’une transaction

Dans le didacticiel Surcapation des modifications de base de données dans un didacticiel sur les transactions, nous avons abordé les techniques d’exécution d’une série d’instructions de modification de base de données dans l’étendue d’une transaction. Rappelez-vous que les modifications effectuées sous l’égide d’une transaction réussissent ou échouent, garantissant l’atomicité. Les techniques d’utilisation des transactions sont les suivantes :

• Utilisation des classes dans l’espace System.Transactions de noms,
• Le fait que la couche d’accès aux données utilise des classes ADO.NET comme SqlTransaction, et
• Ajout des commandes de transaction T-SQL directement dans la procédure stockée

Les modifications de base de données encapsulées au sein d’un didacticiel transactionnel utilisaient les classes ADO.NET dans le dal. Le reste de ce tutoriel explique comment gérer une transaction à l’aide de commandes T-SQL à partir d’une procédure stockée.

Les trois commandes SQL clés pour démarrer, valider et restaurer manuellement une transaction sont BEGIN TRANSACTION, COMMIT TRANSACTIONet ROLLBACK TRANSACTION, respectivement. Comme avec l’approche ADO.NET, lors de l’utilisation de transactions à partir d’une procédure stockée, nous devons appliquer le modèle suivant :

1. Indiquez le début d’une transaction.
2. Exécutez les instructions SQL qui composent la transaction.
3. En cas d’erreur dans l’une des instructions de l’étape 2, restaurez la transaction
4. Si toutes les instructions de l’étape 2 se terminent sans erreur, validez la transaction.

Ce modèle peut être implémenté dans la syntaxe T-SQL à l’aide du modèle suivant :

BEGIN TRY
  BEGIN TRANSACTION -- Start the transaction
  ... Perform the SQL statements that makeup the transaction ...
  -- If we reach here, success!
  COMMIT TRANSACTION
END TRY
BEGIN CATCH 
  -- Whoops, there was an error
  ROLLBACK TRANSACTION
  -- Raise an error with the 
  -- details of the exception   
  DECLARE @ErrMsg nvarchar(4000),
          @ErrSeverity int 
  SELECT @ErrMsg = ERROR_MESSAGE(), 
         @ErrSeverity = ERROR_SEVERITY() 
 
  RAISERROR(@ErrMsg, @ErrSeverity, 1) 
END CATCH

Le modèle commence par définir un TRY...CATCH bloc, une construction nouvelle pour SQL Server 2005. Comme avec try...catch les blocs en C#, le bloc SQL TRY...CATCH exécute les instructions dans le TRY bloc. Si une instruction génère une erreur, le contrôle est immédiatement transféré vers le CATCH bloc.

S’il n’y a aucune erreur lors de l’exécution des instructions SQL qui constituent la transaction, l’instruction COMMIT TRANSACTION valide les modifications et termine la transaction. Si, toutefois, l’une des instructions génère une erreur, le ROLLBACK TRANSACTIONCATCH bloc retourne la base de données à son état avant le début de la transaction. La procédure stockée génère également une erreur à l’aide de la commande RAISERROR, ce qui provoque un SqlException déclenchement dans l’application.

Remarque

Étant donné que le TRY...CATCH bloc est nouveau dans SQL Server 2005, le modèle ci-dessus ne fonctionnera pas si vous utilisez des versions antérieures de Microsoft SQL Server.

Examinons un exemple concret. Une contrainte de clé étrangère existe entre les CategoriesProducts tables, ce qui signifie que chaque CategoryID champ de la Products table doit être mappé à une CategoryID valeur de la Categories table. Toute action qui enfreint cette contrainte, telle que la tentative de suppression d’une catégorie associée aux produits, entraîne une violation de contrainte de clé étrangère. Pour vérifier cela, revisitez l’exemple de mise à jour et de suppression de données binaires existantes dans la section Working with Binary Data (~/BinaryData/UpdatingAndDeleting.aspx). Cette page répertorie chaque catégorie dans le système, ainsi que les boutons Modifier et Supprimer (voir la figure 13), mais si vous tentez de supprimer une catégorie associée à des produits associés( comme boissons), la suppression échoue en raison d’une violation de contrainte de clé étrangère (voir la figure 14).

Figure 13 : Chaque catégorie s’affiche dans un GridView avec des boutons Modifier et Supprimer (cliquez pour afficher l’image de taille complète)

Figure 14 : Vous ne pouvez pas supprimer une catégorie contenant des produits existants (cliquez pour afficher l’image de taille complète)

Imaginez, cependant, que nous voulons autoriser la suppression des catégories, qu’elles aient ou non des produits associés. Si une catégorie avec des produits doit être supprimée, imaginez que nous voulons également supprimer ses produits existants (bien qu’une autre option soit simplement de définir ses valeurs de produits CategoryID sur NULL). Cette fonctionnalité peut être implémentée via les règles en cascade de la contrainte de clé étrangère. Nous pourrions également créer une procédure stockée qui accepte un @CategoryID paramètre d’entrée et, lorsqu’elle est appelée, supprime explicitement tous les produits associés, puis la catégorie spécifiée.

Notre première tentative de procédure stockée peut ressembler à ce qui suit :

CREATE PROCEDURE dbo.Categories_Delete
(
    @CategoryID int
)
AS
-- First, delete the associated products...
DELETE FROM Products
WHERE CategoryID = @CategoryID
-- Now delete the category
DELETE FROM Categories
WHERE CategoryID = @CategoryID

Bien que cela supprime définitivement les produits et la catégorie associés, il ne le fait pas sous l’parapluie d’une transaction. Imaginez qu’il existe une autre contrainte de clé étrangère qui Categories interdit la suppression d’une valeur particulière @CategoryID . Le problème est que dans ce cas, tous les produits seront supprimés avant de tenter de supprimer la catégorie. Le résultat net est que pour une telle catégorie, cette procédure stockée supprimerait tous ses produits alors que la catégorie restait depuis qu’elle a toujours des enregistrements connexes dans une autre table.

Si la procédure stockée a été encapsulée dans l’étendue d’une transaction, toutefois, les suppressions de la Products table sont restaurées face à un échec de suppression sur Categories. Le script de procédure stockée suivante utilise une transaction pour assurer l’atomicité entre les deux DELETE instructions :

CREATE PROCEDURE dbo.Categories_Delete
(
    @CategoryID int
)
AS
BEGIN TRY
  BEGIN TRANSACTION -- Start the transaction
  -- First, delete the associated products...
  DELETE FROM Products
  WHERE CategoryID = @CategoryID
  -- Now delete the category
  DELETE FROM Categories
  WHERE CategoryID = @CategoryID
  -- If we reach here, success!
  COMMIT TRANSACTION
END TRY
BEGIN CATCH 
  -- Whoops, there was an error
  ROLLBACK TRANSACTION
  -- Raise an error with the 
  -- details of the exception   
  DECLARE @ErrMsg nvarchar(4000),
          @ErrSeverity int 
  SELECT @ErrMsg = ERROR_MESSAGE(), 
         @ErrSeverity = ERROR_SEVERITY() 
 
  RAISERROR(@ErrMsg, @ErrSeverity, 1) 
END CATCH

Prenez un moment pour ajouter la Categories_Delete procédure stockée à la base de données Northwind. Reportez-vous à l’étape 1 pour obtenir des instructions sur l’ajout de procédures stockées à une base de données.

Étape 6 : Mise à jour duCategoriesTableAdapter

Pendant que nous avons ajouté la Categories_Delete procédure stockée à la base de données, le dal est actuellement configuré pour utiliser des instructions SQL ad hoc pour effectuer la suppression. Nous devons mettre à jour et CategoriesTableAdapter lui demander d’utiliser la procédure stockée à la Categories_Delete place.

Remarque

Plus haut dans ce tutoriel, nous étions en collaboration avec DataSet NorthwindWithSprocs . Toutefois, DataSet n’a qu’une seule entité, ProductsDataTableet nous devons utiliser des catégories. Par conséquent, pour le reste de ce didacticiel lorsque je parle de la couche d’accès aux données, je fais référence au Northwind DataSet, celui que nous avons créé pour la première fois dans le didacticiel Création d’une couche d’accès aux données.

Ouvrez Northwind DataSet, sélectionnez le CategoriesTableAdapter, puis accédez à la Fenêtre Propriétés. Le Fenêtre Propriétés répertorie les InsertCommandinformations UpdateCommandDeleteCommandde connexion, et SelectCommand utilisées par TableAdapter, ainsi que ses informations de nom et de connexion. Développez la DeleteCommand propriété pour afficher ses détails. Comme le montre la figure 15, la DeleteCommand propriété s’affecte CommandType à Text, ce qui lui indique d’envoyer le texte dans la CommandText propriété en tant que requête SQL ad hoc.

Figure 15 : Sélectionnez le CategoriesTableAdapter concepteur pour afficher ses propriétés dans la fenêtre Propriétés

Pour modifier ces paramètres, sélectionnez le texte (DeleteCommand) dans le Fenêtre Propriétés et choisissez (Nouveau) dans la liste déroulante. Cela efface les paramètres pour les propriétés et CommandText les CommandTypeParameterspropriétés. Ensuite, définissez la CommandType propriété StoredProcedure sur et tapez le nom de la procédure stockée pour le CommandText (dbo.Categories_Delete). Si vous veillez à entrer les propriétés dans cet ordre , commencez par CommandTypeCommandText remplir automatiquement la collection Parameters. Si vous n’entrez pas ces propriétés dans cet ordre, vous devez ajouter manuellement les paramètres via l’Éditeur de collection Parameters. Dans les deux cas, il est prudent de cliquer sur les points de suspension dans la propriété Parameters pour afficher l’éditeur de collection Parameters pour vérifier que les modifications correctes des paramètres ont été apportées (voir la figure 16). Si vous ne voyez aucun paramètre dans la boîte de dialogue, ajoutez le @CategoryID paramètre manuellement (vous n’avez pas besoin d’ajouter le @RETURN_VALUE paramètre).

Figure 16 : Vérifier que les paramètres sont corrects

Une fois que le DAL a été mis à jour, la suppression d’une catégorie supprime automatiquement tous ses produits associés et le fait sous l’parapluie d’une transaction. Pour vérifier cela, revenez à la page Mise à jour et suppression de données binaires existantes, puis cliquez sur le bouton Supprimer pour l’une des catégories. Avec un seul clic de la souris, la catégorie et tous ses produits associés seront supprimés.

Remarque

Avant de tester la Categories_Delete procédure stockée, qui supprime un certain nombre de produits avec la catégorie sélectionnée, il peut être prudent d’effectuer une copie de sauvegarde de votre base de données. Si vous utilisez la NORTHWND.MDF base de données dans App_Data, fermez simplement Visual Studio et copiez les fichiers MDF et LDF dans App_Data un autre dossier. Après avoir testé la fonctionnalité, vous pouvez restaurer la base de données en fermant Visual Studio et en remplaçant les fichiers MDF et LDF actuels par App_Data les copies de sauvegarde.

Résumé

Bien que l’Assistant TableAdapter génère automatiquement des procédures stockées pour nous, il existe des moments où nous pourrions déjà avoir créé de telles procédures stockées ou souhaitez les créer manuellement ou avec d’autres outils à la place. Pour prendre en charge ces scénarios, TableAdapter peut également être configuré pour pointer vers une procédure stockée existante. Dans ce tutoriel, nous avons examiné comment ajouter manuellement des procédures stockées à une base de données via l’environnement Visual Studio et comment connecter les méthodes de TableAdapter à ces procédures stockées. Nous avons également examiné les commandes T-SQL et le modèle de script utilisés pour démarrer, valider et restaurer des transactions à partir d’une procédure stockée.

Bonne programmation !

À propos de l’auteur

Scott Mitchell, auteur de sept livres ASP/ASP.NET et fondateur de 4GuysFromRolla.com, travaille avec les technologies Web Microsoft depuis 1998. Scott travaille en tant que consultant indépendant, formateur et écrivain. Son dernier livre est Sams Teach Yourself ASP.NET 2.0 en 24 heures. On peut le joindre à mitchell@4GuysFromRolla.com.

Merci spécial à

Cette série de tutoriels a été examinée par de nombreux réviseurs utiles. Les réviseurs principaux de ce tutoriel étaient Hilton Geisenow, S ren Jacob Lauritsen et Teresa Murphy. Vous souhaitez consulter mes prochains articles MSDN ? Si c’est le cas, déposez-moi une ligne à mitchell@4GuysFromRolla.com.

PrécédentSuivant