Share via


Limitations du débogage SQL

Mise à jour : novembre 2007

Cette rubrique s'applique à :

Édition

Visual Basic

C#

C++

Web Developer

Express

La rubrique ne s'applique pas La rubrique ne s'applique pas La rubrique ne s'applique pas La rubrique ne s'applique pas

Standard

La rubrique ne s'applique pas La rubrique ne s'applique pas La rubrique ne s'applique pas La rubrique ne s'applique pas

Pro et Team

La rubrique s'applique La rubrique s'applique La rubrique s'applique La rubrique s'applique

Légende du tableau :

La rubrique s'applique

Applicable

La rubrique ne s'applique pas

Non applicable

La rubrique s'applique mais la commande est masquée par défaut

Commande ou commandes masquées par défaut.

Il y a plusieurs limites générales au débogage SQL, que cette section décrit.

Débogage SQL multicouche

  • Lors du débogage d'applications multicouches, vous ne pouvez pas utiliser Pas à pas détaillé pour effectuer un pas à pas à partir du code de la couche Application (C#, Visual Basic ou C++), dans le code sur SQL Server 2005 (T-SQL ou SQL/CLR). La procédure consiste ici à définir un point d'arrêt dans le code de la procédure stockée et à appuyer sur Continuer (F5) afin d'exécuter le code jusqu'au point d'arrêt. Vous pouvez également utiliser Exécuter jusqu'au curseur pour atteindre un point voulu, sans utiliser de point d'arrêt. Notez qu'au sein de la couche SQL Server 2005, vous pouvez commuter entre le code T-SQL et SQL/CLR.

  • De même, il n'est pas possible de procéder à un pas à pas dans l'autre sens, c'est-à-dire depuis le code de la procédure stockée vers le code de la couche qui a appelé cette procédure. Si vous souhaitez continuer à déboguer après être revenu à la couche Application, définissez un point d'arrêt dans votre code d'application à la suite du point à partir duquel la procédure stockée a été appelée.

  • Le regroupement de connexions est une technique qui permet d'améliorer les performances. Lorsqu'une application ferme sa connexion de données, une connexion SQL Server n'est pas complètement fermée mais conservée dans un groupe qui peut être réutilisé par la suite si l'application essaie ultérieurement de rouvrir la connexion. Cependant, lorsqu'une connexion est rétablie via un regroupement de connexions, le débogage SQL n'est pas réactivé.

    Vous devez désactiver temporairement le regroupement de connexions au moment du débogage. Pour cela, définissez "Pooling=false" dans la chaîne de connexion utilisée pour se connecter au SQL Server. Lorsque vous aurez terminé le débogage, supprimez cet attribut de la chaîne de connexion et le regroupement sera réactivé par défaut.

  • Une application managée peut se connecter à une source de données SQL Server en utilisant le fournisseur de données .NET Framework pour SQL Server, qui offre de meilleures performances qu'une connexion avec OLE DB ou ODBC. Vous pouvez effectuer du débogage managé et du débogage SQL dans la même session du débogueur.

    Si une application managée s'exécute et que vous attachez à l'application à l'aide du débogueur, vous avez le choix du type de débogage à effectuer. Si vous souhaitez faire le débogage SQL, vous devez choisir le débogage SQL, et si vous souhaitez déboguer le code SQL/CLR, vous devez également spécifier le débogage managé.

  • Vous pouvez effectuer le débogage SQL après l'attachement à une application en cours d'exécution. Remarquez toutefois que seules les connexions de base de données que vous créez après avoir procédé à l'opération Attacher peuvent être déboguées. Si une application appelle une procédure stockée qui prend beaucoup de temps, vous ne pouvez donc pas réaliser d'attachement à la connexion qui a appelé la procédure stockée, mais seulement aux nouvelles connexions qui appellent la procédure stockée après votre connexion à l'application.

  • Si vous procédez au débogage via une connexion à OleDbDataAdapter, un délai d'attente important après avoir atteint un point d'arrêt provoquera le dépassement de délai de la connexion. Si vous tentez de poursuivre le débogage au-delà de ce délai d'attente (par exemple, en choisissant Continuer dans le menu Déboguer), le débogueur s'arrête au lieu de continuer l'exécution. Ce comportement est prévu. Le débogueur se ferme parce qu'OleDbDataAdapter, contrairement à SqlDataAdapter, ne lève pas d'exception lorsqu'un délai d'attente se produit. Pour résoudre ce problème, définissez une valeur plus élevée pour le délai d'attente lors de l'utilisation d'OleDbDataAdapter.

    Pour plus d'informations sur la définition du délai d'attente pour les fournisseurs de données .NET Framework, consultez OleDbCommand.CommandTimeout, propriété et SqlCommand.CommandTimeout, propriété dans la documentation de la bibliothèque de classes .NET Framework.

    Pour obtenir les informations les plus récentes sur les technologies MDAC, consultez le site Web Microsoft Universal Data Access à l'adresse https://www.microsoft.com/data.

Autres limitations

  • Les déclencheurs doivent être déclenchés pour être débogués : vous ne pouvez pas les déboguer directement. Vous devrez, à la place, commencer le débogage dans une procédure stockée qui provoquera le déclenchement du déclencheur.

  • Pour un débogage en mode exécution, une série de subselects (par exemple, dans une union) peut remplir le netbuffer. Cela peut provoquer l'arrêt, pendant le débogage, d'un code qui fonctionne d'ordinaire correctement. Pour obtenir plus de données, utilisez RecordSet.MoveNext et RecordSet.NextRecordSet.

  • Si le nom d'une procédure stockée contient des guillemets, vous pouvez recevoir un message d'erreur du débogueur. Pour plus d'informations, consultez Erreur lors du débogage de procédures avec des noms qui contiennent des guillemets.

  • Les valeurs mises en cache ne sont pas automatiquement modifiées. Vous ne pouvez pas toujours vous attendre à ce que les modifications apportées aux variables locales ou aux paramètres mises en cache par l'interpréteur SQL prendront effet pendant la durée du pas à pas détaillé dans une instruction SQL. Bien que vous ayez modifié la valeur, elle peut très bien ne plus jamais être vérifiée. Vous ne pouvez pas forcer l'actualisation des valeurs mises en cache. Les valeurs mises en cache existent, car le plan d'exécution de SQL Server détermine que les valeurs pour certaines variables ne seront pas automatiquement chargées pour chaque exécution d'instruction ou référence. Pour plus d'informations, recherchez "SHOWPLAN" dans la documentation de SQL Server 2005.

  • Vous ne pouvez pas effectuer l'attachement au processus SQL Server natif tout en déboguant simultanément une procédure stockée.

Voir aussi

Concepts

Sécurité du débogueur

Débogage de SQL

Limitations appliquées aux commandes et fonctionnalités du débogueur