Débogage des procédures stockées (VB)

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 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 montre 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 riche. Avec quelques frappes 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 logique métier, ils peuvent également être placés dans des procédures stockées.

Dans ce tutoriel, nous allons examiner la procédure stockée à 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 ne peuvent être déboguées que dans les versions Systèmes professionnels et d’équipe 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ées. Autrement dit, vous pouvez créer des objets de base de données tels que des procédures stockées et des User-Defined Functions (UDF) en tant que méthodes dans une classe Visual Basic. Cela permet à ces procédures stockées et UDF d’utiliser des fonctionnalités dans le .NET Framework et à partir de vos propres classes personnalisées. Bien sûr, 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ées. Toutefois, ces objets peuvent uniquement être débogués par le biais des é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ées.

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

• Débogage direct de base de données (DDD) : à partir de Server Explorer nous pouvons entrer dans n’importe quel objet de base de données T-SQL, comme les procédures stockées et les fonctions UDF. 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 entrer 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 UDF où nous voulons que le débogueur s’arrête. Le débogage d’application est examiné à partir de l’étape 2.
• Le débogage à partir d’un SQL Server Project - les éditions Visual Studio Professional et Team Systems incluent un type de projet SQL Server couramment utilisé pour créer des objets de base de données managées. Nous examinerons l’utilisation de SQL Server Projets et le débogage de leur contenu dans le tutoriel suivant.

Visual Studio peut déboguer des procédures stockées sur des instances de SQL Server locales et distantes. Un SQL Server instance local est installé sur le même ordinateur 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 des 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 une SQL Server instance locale, vous pouvez commencer par l’étape 1 et parcourir 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 machine de développement avec un compte d’utilisateur Windows disposant d’une connexion SQL Server sur le instance distant. En outre, cette connexion à la 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, et ainsi de suite. Pour plus d’informations , consultez Limitations sur les commandes et fonctionnalités du débogueur .

Étape 1 : Entrée directe 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 accéder à la Products_SelectByCategoryID procédure stockée dans la base de données Northwind. Comme son nom l’indique, retourne des informations sur le produit pour une catégorie particulière ; Products_SelectByCategoryID elles ont été créées dans le tutoriel Utilisation de procédures stockées existantes pour le didacticiel TableAdapters de Typed DataSet . Commencez par atteindre le Explorer serveur et développez le nœud de base de données Northwind. Ensuite, accédez au dossier Procédures stockées, cliquez avec le bouton droit sur la Products_SelectByCategoryID procédure stockée, puis choisissez l’option Pas à pas 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 paramètre d’entrée @CategoryID , nous sommes invités à fournir cette valeur. Entrez 1, qui retourne des informations sur les boissons.

@CategoryID Parameter » />

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. Au lieu de s’exécuter jusqu’à la fin, cependant, le débogueur arrête l’exécution sur 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 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’atteindre F10 va passer à pas sur l’instruction unique et terminer 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 entrer 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. Lorsqu’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 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_VB). 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 à cocher 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ée 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 plutôt que 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 du chaîne de connexion (ou en le définissant sur 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 commencer le débogage !

Étape 3 : Ajout d’un point d’arrêt et d’un 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 Explorer serveur. Le menu contextuel doit inclure un élément de menu activé nommé Débogage d’application .

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

Une fois 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 jeu de données typé 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 (cliquez 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 Espion de la figure 7, la valeur du @CategoryID paramètre est 1. Cela est dû au fait que la ExistingSprocs.aspx page affiche initialement les produits de la catégorie boissons, qui a une CategoryID valeur de 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 @CategoryID valeur du 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 dans la page web » />

Figure 9 : Le @CategoryID paramètre reflète la catégorie sélectionnée dans la page Web (cliquer 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 d’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 le 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 ordinateurs différents, 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 devez exécuter 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 compte d’utilisateur différent. 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 une explication plus détaillée de ce processus, consultez le guide de William R. Vaughnhitchhiker de Visual Studio et SQL Server, Septième édition.

Notes

Si votre ordinateur 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 que la communication réseau soit effectuée via IPSec, vous devez ouvrir les ports UDP 4500 et UDP 500.

Résumé

Outre 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 détaillé. 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 effectuer un pas à pas détaillé 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 (telle qu’une application web ASP.NET), le programme s’arrête à mesure que 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 allons examiner l’utilisation de projets SQL Server et comment les utiliser pour créer et déboguer des objets de base de données managés 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 Hours. Il est accessible à l’adressemitchell@4GuysFromRolla.com . ou via son blog, qui se trouve à l’adresse http://ScottOnWriting.NET.

PrécédentSuivant