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 d’effectuer des étapes dans 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 didacticiel illustre le débogage direct de la base de données et le débogage des applications des procédures stockées.

Présentation

Visual Studio offre une expérience de débogage riche. 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 une classe de couche logique métier, de sorte qu’ils peuvent également être placés dans des procédures stockées.

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

Remarque

Malheureusement, il n'est possible de s'introduire dans et de déboguer les procédures stockées qu'avec les versions Professional et Team Systems de Visual Studio. Si vous utilisez Visual Web Developer ou la version standard de Visual Studio, vous êtes invité à lire le long des étapes nécessaires pour déboguer des procédures stockées, mais vous ne pourrez pas répliquer ces étapes sur votre ordinateur.

Concepts de débogage de SQL Server

Microsoft SQL Server 2005 a été conçu pour fournir une intégration au 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 Visual Basic. Cela permet à ces procédures stockées et aux fonctions définies par l’utilisateur d’utiliser des fonctionnalités dans le .NET Framework et à partir 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 de base de données T-SQL et managés. 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és.

La vue d’ensemble du débogage T-SQL et CLR dans SQL Server 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 l’Explorateur de serveurs, nous pouvons effectuer un pas à pas 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 examinerons 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 accéder à un objet de base de données depuis le code de l'application. Nous devons définir explicitement des points d'arrêt dans ces procédures stockées ou fonctions définies par l'utilisateur où nous voulons que le débogueur s'arrête. Le débogage d'une application est examiné à partir de l'étape 2.
• Le débogage à partir d’un projet SQL Server - 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és. Nous examinerons 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. Une instance SQL Server locale est une instance installée sur le même ordinateur que Visual Studio. Si la base de données SQL Server que vous utilisez n’est pas située sur votre ordinateur de développement, elle est considérée comme une instance distante. Pour ces didacticiels, nous utilisons des instances SQL Server locales. Le débogage de procédures stockées sur une instance sql server distante nécessite plus d’étapes de configuration que lors du débogage de procédures stockées sur une instance locale.

Si vous utilisez une instance SQL Server locale, vous pouvez commencer par l’étape 1 et suivre ce didacticiel jusqu’à la fin. Toutefois, si vous utilisez une instance SQL Server distante, 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 l’instance distante. De plus, 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 des objets de base de données T-SQL sur les instances distantes à la fin de ce didacticiel pour plus d’informations sur la configuration de Visual Studio et de SQL Server pour déboguer une instance distante.

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 relatives aux commandes et fonctionnalités du débogueur .

Étape 1 : Entrer directement dans une procédure enregistrée

Visual Studio facilite le débogage direct d’un objet de base de données. Examinons comment utiliser la fonctionnalité de débogage direct de base de données (DDD) pour entrer 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 de produit concernant une catégorie particulière ; elle a été créée dans le didacticiel Utilisation de procédures stockées existantes pour les TableAdapters de Typed DataSet. Commencez par accéder à l’Explorateur de serveurs 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, 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 pour obtenir 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 d’exécuter jusqu’à la fin, le débogueur interrompt l’exécution sur la première instruction. Notez la flèche jaune située en 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 de surveillance ou en survolant 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 de taille complète)

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, de sorte qu’en appuyant sur F10, on passe sur l'instruction unique et termine l’exécution de celle-ci. Une fois la procédure stockée achevée, son résultat s'affichera dans la fenêtre de sortie et le débogueur s'arrêtera.

Remarque

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’applications

Bien que le débogage d’une procédure stockée directement à partir de l’Explorateur de serveurs 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 pouvoir démarrer le débogage 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 l’Explorateur de solutions (ASPNET_Data_Tutorial_74_VB). Sélectionnez l’option Pages de propriétés dans le menu contextuel, sélectionnez l’élément Options de démarrage à gauche, puis cochez la case SQL Server dans la section Débogueurs (voir la figure 3).

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

En outre, nous devons mettre à jour la chaîne de connexion de base de données 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 de devoir 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 extraite du pool.

Pour désactiver le regroupement de connexions, mettez à jour l’élément NORTHWNDConnectionString dans Web.config afin qu’il inclut 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>

Remarque

Une fois que vous avez terminé le débogage de 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 le définissant sur Pooling=true ).

À ce stade, l’application ASP.NET a été configurée pour permettre à Visual Studio de déboguer des objets de base de données SQL Server lorsqu’elle est appelée via l’application web. Tout ce qui reste maintenant est d’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 (cliquez pour afficher l’image de taille complète)

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 d’abord un point d’arrêt, ce paramètre doit automatiquement être activé, mais il est prudent de vérifier deux fois. Cliquez avec le bouton droit sur le NORTHWND.MDF nœud dans l’Explorateur de serveurs. Le menu contextuel doit inclure un élément de menu vérifié nommé Débogage d’application.

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

Avec le point d'arrêt défini et l’option de 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ébogage 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 des procédures stockées existantes pour les TableAdapters des DataSets typés. 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 Products_SelectByCategoryID procédure stockée est atteint et le contrôle retourné à Visual Studio. Comme à l’étape 1, vous pouvez parcourir les instructions de 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 pleine taille)

Figure 7 : Le point d’arrêt de la procédure stockée a été atteint (cliquez pour afficher l’image de taille complète)

Comme le montre la fenêtre de surveillance dans la figure 7, la valeur du paramètre @CategoryID est 1. Cela est dû au fait que la ExistingSprocs.aspx page affiche initialement des produits dans la catégorie boissons, qui a la CategoryID valeur 1. Choisissez une autre catégorie dans la liste déroulante. Cela provoque une réactualisation 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 les éléments de liste déroulante sélectionnés CategoryID.

Figure 8 : Choisir une catégorie différente dans la liste Drop-Down (cliquez pour afficher l’image de taille complète)

@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 à partir de la page web (cliquez pour afficher l’image de taille complète)

Remarque

Si le point d’arrêt de la procédure stockée Products_SelectByCategoryID n’est pas atteint lors de la visite de la page ExistingSprocs.aspx, assurez-vous que l'option SQL Server est cochée dans la section Débogueurs de la page des propriétés de l'application ASP.NET, que le pool 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 de base de données T-SQL 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 différents ordinateurs, une configuration minutieuse est nécessaire pour que tout fonctionne correctement. Il existe deux tâches principales auxquelles nous sommes confrontés :

• 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, le compte Windows que vous avez connecté à votre station de travail n’est pas une connexion valide sur SQL Server. Au lieu 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’une instance SQL Server distante, vous exécutez Visual Studio à l’aide des informations d’identification du compte de connexion Windows.

Un exemple doit aider à clarifier les choses. Imaginez qu’il existe un compte Windows nommé SQLDebug dans le domaine Windows. Ce compte doit être ajouté à l’instance SQL Server distante en tant que connexion valide et en tant que membre du sysadmin rôle. Ensuite, pour déboguer l’instance SQL Server distante à partir de Visual Studio, nous devons exécuter Visual Studio en tant qu’utilisateur SQLDebug . 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 consiste à se 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 à une application particulière d’être exécutée sous la forme d’un autre compte d’utilisateur. Pour lancer Visual Studio en tant que SQLDebug, vous pouvez entrer l’instruction suivante à 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 sur ce processus, consultez le Guide du Hitchhiker de William R. Vaughnpour Visual Studio et SQL Server, Septième Édition.

Remarque

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 DE SQL Server 2005 remarque que cela implique deux étapes : (a) Sur l’ordinateur hôte Visual Studio, vous devez ajouter Devenv.exe à la liste 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 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’applications. Pour déboguer directement un objet de base de données T-SQL, localisez l'objet via l'Explorateur de serveurs, puis cliquez dessus avec le bouton droit et choisissez Entrer dans le débogueur. Cela démarre le débogueur et s’arrête sur la première instruction de l’objet de base de données, à quel moment 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’applications 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 à mesure que le débogueur prend le relais. Le débogage d’application est utile, car il montre plus clairement quelle action d’application entraîne 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 la base de données.

Les objets de base de données peuvent également être débogués via des projets SQL Server. 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 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.

PrécédentSuivant