Débogage des procédures stockées (C#)

par Scott Mitchell

Télécharger le PDF

les éditions Visual Studio Professional et Team System vous permettent de définir des points d’arrêt et d’exécuter des procédures stockées dans SQL Server, ce qui facilite le débogage des procédures stockées comme le débogage du code d’application. Ce tutoriel illustre le débogage direct de base de données et le débogage d’application des procédures stockées.

Introduction

Visual Studio offre une expérience de débogage enrichie. Avec quelques séquences de touches ou clics de la souris, il est possible d’utiliser des points d’arrêt pour arrêter l’exécution d’un programme et examiner son état et son flux de contrôle. En plus du débogage du code d’application, Visual Studio prend en charge le débogage des procédures stockées à partir de SQL Server. Tout comme les points d’arrêt peuvent être définis dans le code d’une classe code-behind ASP.NET ou d’une classe de couche de logique métier, ils peuvent également être placés dans des procédures stockées.

Dans ce tutoriel, nous allons examiner la procédure pas à pas dans les procédures stockées à partir du serveur Explorer dans Visual Studio, ainsi que la façon de définir les points d’arrêt qui sont atteints lorsque la procédure stockée est appelée à partir de l’application ASP.NET en cours d’exécution.

Notes

Malheureusement, les procédures stockées peuvent uniquement être intégrées et déboguées via les versions Professional et Team Systems de Visual Studio. Si vous utilisez Visual Web Developer ou la version standard de Visual Studio, nous vous invitons à lire les étapes nécessaires pour déboguer les procédures stockées, mais vous ne pourrez pas répliquer ces étapes sur votre ordinateur.

concepts de débogage SQL Server

Microsoft SQL Server 2005 a été conçu pour fournir une intégration avec le Common Language Runtime (CLR), qui est le runtime utilisé par tous les assemblys .NET. Par conséquent, SQL Server 2005 prend en charge les objets de base de données managés. Autrement dit, vous pouvez créer des objets de base de données tels que des procédures stockées et des fonctions User-Defined (UDF) en tant que méthodes dans une classe C#. Cela permet à ces procédures stockées et fonctions définies par l’utilisateur d’utiliser les fonctionnalités du .NET Framework et de vos propres classes personnalisées. Bien entendu, SQL Server 2005 prend également en charge les objets de base de données T-SQL.

SQL Server 2005 offre une prise en charge du débogage pour les objets T-SQL et de base de données managée. Toutefois, ces objets peuvent uniquement être débogués via les éditions Visual Studio 2005 Professional et Team Systems. Dans ce tutoriel, nous allons examiner le débogage d’objets de base de données T-SQL. Le tutoriel suivant examine le débogage d’objets de base de données managée.

L’article de blog Vue d’ensemble du débogage T-SQL et CLR dans SQL Server 2005 de l’équipe d’intégration du CLR SQL Server 2005 met en évidence les trois façons de déboguer SQL Server objets 2005 à partir de Visual Studio :

• Débogage direct de base de données (DDD) : à partir de Server Explorer nous pouvons effectuer un pas à pas détaillé dans n’importe quel objet de base de données T-SQL, tel que les procédures stockées et les fonctions définies par l’utilisateur. Nous allons examiner DDD à l’étape 1.
• Débogage d’application : nous pouvons définir des points d’arrêt dans un objet de base de données, puis exécuter notre application ASP.NET. Lorsque l’objet de base de données est exécuté, le point d’arrêt est atteint et le contrôle est remis au débogueur. Notez qu’avec le débogage d’application, nous ne pouvons pas effectuer un pas à pas détaillé dans un objet de base de données à partir du code d’application. Nous devons définir explicitement des points d’arrêt dans les procédures stockées ou les fonctions définies par l’utilisateur où le débogueur doit s’arrêter. Le débogage d’application est examiné à partir de l’étape 2.
• Le débogage à partir d’un SQL Server Project - éditions Visual Studio Professional et Team Systems inclut un type de projet SQL Server couramment utilisé pour créer des objets de base de données managés. Nous allons examiner l’utilisation de projets SQL Server et le débogage de leur contenu dans le tutoriel suivant.

Visual Studio peut déboguer des procédures stockées sur des instances SQL Server locales et distantes. Un SQL Server instance local est installé sur la même machine que Visual Studio. Si la base de données SQL Server que vous utilisez ne se trouve pas sur votre ordinateur de développement, elle est considérée comme une instance distante. Pour ces tutoriels, nous avons utilisé des instances de SQL Server locales. Le débogage de procédures stockées sur un serveur SQL distant instance nécessite plus d’étapes de configuration que lors du débogage de procédures stockées sur un instance local.

Si vous utilisez un SQL Server instance local, vous pouvez commencer par l’étape 1 et suivre ce didacticiel jusqu’à la fin. Toutefois, si vous utilisez un SQL Server instance distant, vous devez d’abord vous assurer que, lors du débogage, vous êtes connecté à votre ordinateur de développement avec un compte d’utilisateur Windows disposant d’une connexion SQL Server sur le instance distant. En outre, cette connexion de base de données et la connexion de base de données utilisée pour se connecter à la base de données à partir de l’application ASP.NET en cours d’exécution doivent être membres du sysadmin rôle. Consultez la section Débogage d’objets T-SQL Database sur des instances distantes à la fin de ce didacticiel pour plus d’informations sur la configuration de Visual Studio et SQL Server pour déboguer un instance distant.

Enfin, comprenez que la prise en charge du débogage pour les objets de base de données T-SQL n’est pas aussi riche en fonctionnalités que la prise en charge du débogage pour les applications .NET. Par exemple, les conditions de point d’arrêt et les filtres ne sont pas pris en charge, seul un sous-ensemble des fenêtres de débogage est disponible, vous ne pouvez pas utiliser Modifier et Continuer, la fenêtre Exécution est rendue inutile, etc. Pour plus d’informations , consultez Limitations sur les commandes et fonctionnalités du débogueur .

Étape 1 : Pas à pas directement dans une procédure stockée

Visual Studio facilite le débogage direct d’un objet de base de données. Voyons comment utiliser la fonctionnalité Débogage direct de base de données (DDD) pour effectuer un pas à pas détaillé dans la Products_SelectByCategoryID procédure stockée dans la base de données Northwind. Comme son nom l’indique, Products_SelectByCategoryID retourne des informations produit pour une catégorie particulière ; elles ont été créées dans le didacticiel Utilisation de procédures stockées existantes pour le dataset typé TableAdapters . Commencez par atteindre le serveur Explorer et développez le nœud de base de données Northwind. Ensuite, explorez le dossier Procédures stockées, cliquez avec le bouton droit sur la Products_SelectByCategoryID procédure stockée et choisissez l’option Pas à pas détaillé dans la procédure stockée dans le menu contextuel. Cela démarre le débogueur.

Étant donné que la Products_SelectByCategoryID procédure stockée attend un @CategoryID paramètre d’entrée, nous sommes invités à fournir cette valeur. Entrez 1, qui renverra des informations sur les boissons.

@CategoryID » />

Figure 1 : Utiliser la valeur 1 pour le @CategoryID paramètre

Après avoir fourni la valeur du @CategoryID paramètre, la procédure stockée est exécutée. Toutefois, au lieu de s’exécuter jusqu’à la fin, le débogueur arrête l’exécution de la première instruction. Notez la flèche jaune dans la marge, indiquant l’emplacement actuel dans la procédure stockée. Vous pouvez afficher et modifier les valeurs des paramètres via la fenêtre Espion ou en pointant sur le nom du paramètre dans la procédure stockée.

Figure 2 : Le débogueur s’est arrêté sur la première instruction de la procédure stockée (cliquez pour afficher l’image en taille réelle)

Pour parcourir la procédure stockée une instruction à la fois, cliquez sur le bouton Pas à pas précédent dans la barre d’outils ou appuyez sur la touche F10. La Products_SelectByCategoryID procédure stockée contient une instruction unique SELECT . Par conséquent, le fait d’appuyer sur F10 entraîne l’exécution de l’instruction unique et termine l’exécution de la procédure stockée. Une fois la procédure stockée terminée, sa sortie s’affiche dans la fenêtre Sortie et le débogueur se termine.

Notes

Le débogage T-SQL se produit au niveau de l’instruction ; vous ne pouvez pas effectuer de pas à pas détaillé dans une SELECT instruction.

Étape 2 : Configuration du site web pour le débogage d’application

Bien que le débogage d’une procédure stockée directement à partir du serveur Explorer soit pratique, dans de nombreux scénarios, nous sommes plus intéressés par le débogage de la procédure stockée lorsqu’elle est appelée à partir de notre application ASP.NET. Nous pouvons ajouter des points d’arrêt à une procédure stockée à partir de Visual Studio, puis commencer à déboguer l’application ASP.NET. Quand une procédure stockée avec des points d’arrêt est appelée à partir de l’application, l’exécution s’arrête au point d’arrêt et nous pouvons afficher et modifier les valeurs des paramètres de la procédure stockée et parcourir ses instructions, comme nous l’avons fait à l’étape 1.

Avant de pouvoir commencer à déboguer des procédures stockées appelées à partir de l’application, nous devons demander à l’application web ASP.NET de s’intégrer au débogueur SQL Server. Commencez par cliquer avec le bouton droit sur le nom du site web dans le Explorateur de solutions (ASPNET_Data_Tutorial_74_CS). Choisissez l’option Pages de propriétés dans le menu contextuel, sélectionnez l’élément Options de démarrage à gauche et case activée la case à cocher SQL Server dans la section Débogueurs (voir figure 3).

Figure 3 : Cochez la case SQL Server dans les pages de propriétés de l’application (cliquez pour afficher l’image en taille réelle)

En outre, nous devons mettre à jour la base de données chaîne de connexion utilisées par l’application afin que le regroupement de connexions soit désactivé. Lorsqu’une connexion à une base de données est fermée, l’objet correspondant SqlConnection est placé dans un pool de connexions disponibles. Lors de l’établissement d’une connexion à une base de données, un objet de connexion disponible peut être récupéré à partir de ce pool au lieu d’avoir à créer et établir une nouvelle connexion. Ce regroupement d’objets de connexion est une amélioration des performances et est activé par défaut. Toutefois, lors du débogage, nous voulons désactiver le regroupement de connexions, car l’infrastructure de débogage n’est pas correctement rétablie lors de l’utilisation d’une connexion qui a été prise à partir du pool.

Pour désactiver le regroupement de connexions, mettez à jour le NORTHWNDConnectionString dans Web.config afin qu’il inclue le paramètre Pooling=false .

<connectionStrings>
    <add name="NORTHWNDConnectionString" connectionString=
        "Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\NORTHWND.MDF;
            Integrated Security=True;User Instance=True;Pooling=false"
        providerName="System.Data.SqlClient" />
</connectionStrings>

Notes

Une fois que vous avez terminé le débogage SQL Server via l’application ASP.NET veillez à rétablir le regroupement de connexions en supprimant le Pooling paramètre de la chaîne de connexion (ou en lui affectant la valeur Pooling=true ).

À ce stade, l’application ASP.NET a été configurée pour permettre à Visual Studio de déboguer SQL Server objets de base de données lorsqu’ils sont appelés via l’application web. Il ne reste plus qu’à ajouter un point d’arrêt à une procédure stockée et à démarrer le débogage !

Étape 3 : Ajout d’un point d’arrêt et débogage

Ouvrez la Products_SelectByCategoryID procédure stockée et définissez un point d’arrêt au début de l’instruction SELECT en cliquant dans la marge à l’emplacement approprié ou en plaçant votre curseur au début de l’instruction SELECT et en appuyant sur F9. Comme l’illustre la figure 4, le point d’arrêt apparaît sous la forme d’un cercle rouge dans la marge.

Figure 4 : Définir un point d’arrêt dans la Products_SelectByCategoryID procédure stockée (cliquer pour afficher l’image en taille réelle)

Pour qu’un objet de base de données SQL soit débogué via une application cliente, il est impératif que la base de données soit configurée pour prendre en charge le débogage d’application. Lorsque vous définissez un point d’arrêt pour la première fois, ce paramètre doit être automatiquement activé, mais il est prudent de double case activée. Cliquez avec le bouton droit sur le NORTHWND.MDF nœud dans le serveur Explorer. Le menu contextuel doit inclure un élément de menu activé nommé Débogage d’application.

Figure 5 : Vérifiez que l’option Débogage d’application est activée

Avec le point d’arrêt défini et l’option Débogage d’application activée, nous sommes prêts à déboguer la procédure stockée lorsqu’elle est appelée à partir de l’application ASP.NET. Démarrez le débogueur en accédant au menu Déboguer et en choisissant Démarrer le débogage, en appuyant sur F5 ou en cliquant sur l’icône de lecture verte dans la barre d’outils. Cela démarre le débogueur et lance le site web.

La Products_SelectByCategoryID procédure stockée a été créée dans le didacticiel Utilisation de procédures stockées existantes pour le dataset typé s TableAdapters . Sa page web correspondante (~/AdvancedDAL/ExistingSprocs.aspx) contient un GridView qui affiche les résultats retournés par cette procédure stockée. Visitez cette page via le navigateur. Une fois la page atteinte, le point d’arrêt de la procédure stockée est atteint et le Products_SelectByCategoryID contrôle est retourné à Visual Studio. Tout comme à l’étape 1, vous pouvez parcourir les instructions de la procédure stockée et afficher et modifier les valeurs des paramètres.

Figure 6 : La ExistingSprocs.aspx page affiche initialement les boissons (cliquer pour afficher l’image en taille réelle)

Figure 7 : Le point d’arrêt de la procédure stockée a été atteint (cliquer pour afficher l’image en taille réelle)

Comme le montre la fenêtre Watch de la figure 7, la valeur du @CategoryID paramètre est 1. Cela s’explique par le fait que la ExistingSprocs.aspx page affiche initialement les produits de la catégorie boissons, qui a la CategoryID valeur 1. Choisissez une autre catégorie dans la liste déroulante. Cela entraîne une publication et réexécute la Products_SelectByCategoryID procédure stockée. Le point d’arrêt est à nouveau atteint, mais cette fois la valeur s du @CategoryID paramètre reflète l’élément de liste déroulante sélectionné s CategoryID.

Figure 8 : Choisir une autre catégorie dans la liste Drop-Down (cliquer pour afficher l’image en taille réelle)

@CategoryID reflète la catégorie sélectionnée à partir de la page web » />

Figure 9 : Le @CategoryID paramètre reflète la catégorie sélectionnée dans la page web (cliquez pour afficher l’image en taille réelle)

Notes

Si le point d’arrêt de la Products_SelectByCategoryID procédure stockée n’est pas atteint lors de la visite de la ExistingSprocs.aspx page, vérifiez que la case à cocher SQL Server a été cochée dans la section Débogueurs de la page Propriétés de l’application ASP.NET, que le regroupement de connexions a été désactivé et que l’option Débogage de l’application de la base de données est activée. Si vous rencontrez toujours des problèmes, redémarrez Visual Studio et réessayez.

Débogage d’objets T-SQL Database sur des instances distantes

Le débogage d’objets de base de données via Visual Studio est assez simple lorsque l’instance de base de données SQL Server se trouve sur la même machine que Visual Studio. Toutefois, si SQL Server et Visual Studio résident sur des machines différentes, une configuration minutieuse est nécessaire pour que tout fonctionne correctement. Nous sommes confrontés à deux tâches principales :

• Vérifiez que la connexion utilisée pour se connecter à la base de données via ADO.NET appartient au sysadmin rôle.
• Vérifiez que le compte d’utilisateur Windows utilisé par Visual Studio sur l’ordinateur de développement est un compte de connexion SQL Server valide qui appartient au sysadmin rôle.

La première étape est relativement simple. Tout d’abord, identifiez le compte d’utilisateur utilisé pour se connecter à la base de données à partir de l’application ASP.NET, puis, à partir de SQL Server Management Studio, ajoutez ce compte de connexion au sysadmin rôle.

La deuxième tâche nécessite que le compte d’utilisateur Windows que vous utilisez pour déboguer l’application soit une connexion valide sur la base de données distante. Toutefois, il est probable que le compte Windows avec lequel vous vous êtes connecté à votre station de travail ne soit pas une connexion valide sur SQL Server. Plutôt que d’ajouter votre compte de connexion particulier à SQL Server, il est préférable de désigner un compte d’utilisateur Windows comme compte de débogage SQL Server. Ensuite, pour déboguer les objets de base de données d’un SQL Server instance distant, vous exécutez Visual Studio à l’aide des informations d’identification de ce compte de connexion Windows.

Un exemple devrait vous aider à clarifier les choses. Imaginez qu’il existe un compte Windows nommé SQLDebug dans le domaine Windows. Ce compte doit être ajouté au SQL Server instance distant en tant que connexion valide et en tant que membre du sysadmin rôle. Ensuite, pour déboguer le SQL Server instance distant à partir de Visual Studio, nous devons exécuter Visual Studio en tant qu’utilisateurSQLDebug. Pour ce faire, vous pouvez vous déconnecter de notre station de travail, vous reconnecter en tant que SQLDebug, puis lancer Visual Studio, mais une approche plus simple consisterait à vous connecter à notre station de travail à l’aide de nos propres informations d’identification, puis à utiliser runas.exe pour lancer Visual Studio en tant qu’utilisateur SQLDebug . runas.exe permet l’exécution d’une application particulière sous le couvert d’un autre compte d’utilisateur. Pour lancer Visual Studio en tant que SQLDebug, vous pouvez entrer l’instruction suivante sur la ligne de commande :

runas.exe /user:SQLDebug "%PROGRAMFILES%\Microsoft Visual Studio 8\Common7\IDE\devenv.exe"

Pour obtenir des explications plus détaillées sur ce processus, consultez Guide de William R. VaughnHitchhiker pour Visual Studio et SQL Server, Septième édition.

Notes

Si votre machine de développement exécute Windows XP Service Pack 2, vous devez configurer le pare-feu de connexion Internet pour autoriser le débogage à distance. L’article Guide pratique pour activer le débogage SQL Server 2005 indique que cela implique deux étapes : (a) Sur l’ordinateur hôte Visual Studio, vous devez ajouter Devenv.exe à la liste des exceptions et ouvrir le port TCP 135 ; et (b) Sur l’ordinateur distant (SQL), vous devez ouvrir le port TCP 135 et ajouter sqlservr.exe à la liste des exceptions. Si votre stratégie de domaine nécessite une communication réseau via IPSec, vous devez ouvrir les ports UDP 4500 et UDP 500.

Résumé

En plus de fournir la prise en charge du débogage pour le code d’application .NET, Visual Studio fournit également diverses options de débogage pour SQL Server 2005. Dans ce tutoriel, nous avons examiné deux de ces options : débogage direct de base de données et débogage d’application. Pour déboguer directement un objet de base de données T-SQL, recherchez l’objet via le serveur Explorer cliquez dessus avec le bouton droit et choisissez Pas à pas. Cela démarre le débogueur et s’arrête sur la première instruction de l’objet de base de données, à partir duquel vous pouvez parcourir les instructions de l’objet et afficher et modifier les valeurs des paramètres. À l’étape 1, nous avons utilisé cette approche pour entrer dans la Products_SelectByCategoryID procédure stockée.

Le débogage d’application permet de définir des points d’arrêt directement dans les objets de base de données. Lorsqu’un objet de base de données avec des points d’arrêt est appelé à partir d’une application cliente (par exemple, une application web ASP.NET), le programme s’arrête lorsque le débogueur prend le relais. Le débogage d’application est utile, car il montre plus clairement quelle action d’application provoque l’appel d’un objet de base de données particulier. Toutefois, il nécessite un peu plus de configuration et d’installation que le débogage direct de base de données.

Les objets de base de données peuvent également être débogués via SQL Server Projects. Nous examinerons l’utilisation de SQL Server projets et la façon de les utiliser pour créer et déboguer des objets de base de données managées dans le tutoriel suivant.

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 comme consultant indépendant, formateur et écrivain. Son dernier livre est Sams Teach Yourself ASP.NET 2.0 in 24 Heures. Il est accessible à l’adressemitchell@4GuysFromRolla.com . ou via son blog, qui peut être trouvé à l’adresse http://ScottOnWriting.NET.

PrécédentSuivant