I’m trying to debug a rather complicated formula evaluator written in T-SQL UDFs (don’t ask) that recursively (but indirectly through an intermediate function) calls itself, blah, blah.
And, of course, we have a bug.
Now, using PRINT statements (that can then be read from ADO.NET by implementing a handler for the InfoMessage event), I can simulate a trace for stored procedures.
Doing the same for UDF results in a compile time message:
Invalid use of side-effecting or time-dependent operator in 'PRINT' within a function. I get the message (PRINT does some stuff like resetting @@ROWCOUNT which definitly is a no-no in UDFs, but how can I trace through the calls? I want to have this trace printed out, so I can study it without getting distracted by stepping through the calls in the debugger…
EDIT: I have tried to use the SQL Profiler (this was a first time one for me), but I can’t figure out what to trace for: Although I can get the trace to output the queries sent to the database, they are opaque in the sense that I can’t drill down to the Expression-UDFs called: I can trace the actual Stored Procedure invoked, but the UDFs called by this procedure are not listed. Am I missing something? I guess not…
EDIT #2: Allthough the (auto-)accepted answer does trace the function calls – very helpful, thanks – it does not help in finding out what parameters were passed to the function. This, of course, is essential in debugging recursive functions. I will post if I find any sollution at all…
Why not use SQL Profiler with statement level events added?
Edit: Add events for Stored Procedures : SP:Stmt Starting or SP:Stmt Completed Use variables to debug if needed, i.e. set @debug=’i am here’; UDF’s, while not technically stored procedures, will get traced with the statement level events.