Comment tracer les appels de fonction T-SQL

dans le profileur SQL, vous avez besoin de:SP:Starting, SP:StmtStarting, SP:Completed, SQL: BatchStarting. Ensuite, vous obtenez chaque entrée, sortie des fonctions / procédures stockées.

alter FUNCTION [dbo].[ufn_mjf](@i numeric(10))
    RETURNS numeric(20) 
AS
BEGIN
declare @datapoint varchar(10)

    set @datapoint = 'hello world'

    return @i
END
go
drop table foo
go
create table dbo.foo ( foo_id numeric(10)) 
go
delete from foo
insert into foo ( foo_id ) values ( 1 )
insert into foo ( foo_id ) values ( 2 )

select foo_id, dbo.ufn_mjf(foo_id) from foo

avec ceci, je reçois:

SQL:BatchStarting   alter FUNCTION [dbo].[ufn_mjf](@i numeric(10))
SQL:BatchStarting   drop table foo
SQL:BatchStarting   create table dbo.foo ( foo_id numeric(10)) 
SQL:BatchStarting   delete from foo
    insert into foo ( foo_id ) values ( 1 )
    insert into foo ( foo_id ) values ( 2 )
    select foo_id, dbo.ufn_mjf(foo_id) from foo
SP:Starting select foo_id, dbo.ufn_mjf(foo_id) from foo
SP:StmtStarting set @datapoint = 'hello world'
SP:StmtStarting return @i
SP:Completed    select foo_id, dbo.ufn_mjf(foo_id) from foo
SP:Starting select foo_id, dbo.ufn_mjf(foo_id) from foo
SP:StmtStarting set @datapoint = 'hello world'
SP:StmtStarting return @i
SP:Completed    select foo_id, dbo.ufn_mjf(foo_id) from foo

ça vous suffit?

ce ressemble à ce dont vous avez besoin, mais il est seulement disponible dans les versions team/pro de Visual Studio.

utilisez SQL Profiler, je vous recommande d'aller trop loin sur l'ajout d'événements la première fois qui vous permettra d'avoir une idée de ce dont vous avez besoin. Sans tester, j'ajouterais les évènements pour SP:StmtStarted (ou Completed ou les deux), SQL: StmtStarted (à nouveau Completed ou les deux).

j'appuie la suggestion du profileur SQL. Prenez le temps de le configurer de sorte que seuls les événements qui vous intéressent sont connecté pour couper la taille de sortie. Vous pouvez afficher la trace d'un fichier - j'ai souvent chargé ce fichier de nouveau dans une table pour permettre l'analyse. (extrêmement pratique pour l'analyse de performance, bien que nul doute que quelqu'un me dira que 2008 a tout cela construit dans Somwhere...)

parfois vous n'aurez pas les permissions D'exécuter le profileur SQL car il ralentit le serveur est en panne - demandez à votre DBA de vous accorder la permission sur votre serveur Dev. Ils ne devraient pas avoir de problème avec ça.

Eh bien dans le passé j'ai dû prendre des valeurs typiques qui seraient dans L'UDF et puis exécuter juste la partie udf dans une fenêtre de requête séparée comme SQL droit pas un udf en utilisant les valeurs typiques comme variables définies avec un declare et une instruction set. Si elle est exécutée à partir d'une table au lieu d'avoir une seule valeur, je mettrais en place une table temp table ou une variable table avec les valeurs d'entrée et les lancerais ensuite à travers le sql dans L'UDF (mais encore une fois en tant que SQL droit pas un UDF) à travers un curseur. En exécutant vous pourriez avoir des instructions d'impression pour voir ce qui se passe. Je sais que c'est une douleur, mais il fonctionne. (Je passe par un processus simliar lors de la création/débogage des triggers, setup #insered et #deleted avec mes valeurs de test et ensuite tester le code que j'ai l'intention de mettre dans la trigger, puis global remplacer le # par rien et ajouter le code de Trigger create.)

peut-être Pouvez-vous utiliser SQL CLR pour faire le traçage comme décrit ici comment se connecter T-SQL

pouvez-vous prendre votre fonction, et en faire une deuxième copie, mais en retournant un type de table avec une colonne supplémentaire pour vos informations de débogage.

par exemple, la fonction mySum ci-dessous

CREATE FUNCTION mySum
(   
    @param1 int,
    @param2 int
)
RETURNS INT AS
BEGIN
    DECLARE @mySum int

    SET @mySum = @param1

    SET @mySum = @mySum + @param2

    RETURN @mySum

END
GO
SELECT dbo.mySum(1, 2)

se transformerait en

CREATE FUNCTION mySumDebug
(   
    @param1 int,
    @param2 int
)
RETURNS @myTable TABLE
(
    [mySum] int,
    [debug] nvarchar(max)
)
AS
BEGIN
    DECLARE @debug nvarchar(max)

    SET @debug = 'Declare @mySum variable. '
    DECLARE @mySum int

    SET @debug = @debug + 'Set @mySum = @param1(' + CONVERT(nvarchar(50), @param1) + ') '
    SET @mySum = @param1


    SET @debug = @debug + 'Add @param2(' + CONVERT(nvarchar(50), @param2) + ') to @mySum(' + CONVERT(nvarchar(50), @mySum) + ') '
    SET @mySum = @mySum + @param2

    SET @debug = @debug + 'Return @mySum variable. '

    INSERT @myTable (mySum, debug) VALUES (@mySum, @debug)

    RETURN
END
GO
SELECT mySum, debug FROM dbo.mySumDebug(1, 2)

ce n'est pas une solution idéale, mais il est utile de simplement renvoyer du texte pour aider à dépister un bogue.

J'utilise SQL SPY qui fait ce que vous cherchez et plus.

SQL SPY

SQL ESPION de la Documentation sur la Fonctionnalité

SQL SPY's Incoming SQL Sniffer affiche le code SQL entrant de chaque connexion (y compris le suivi des déclarations DDL et DML)

cette fonctionnalité est conçu pour MS SQL Server 2005 \ 2008, mais fonctionnera avec MS SQL Server 2000 en Limité portée. Il a la capacité d'enregistrer et de signaler sur SQL entrant. Comment utiliser les fonctionnalités: Voir

Divulgation: je suis partie de la SQL ESPION de l'équipe.