How to view data in table variables during debuggi

问题:

I would like to debug a complex T-SQL script using SSMS 2012.

I can run the script in debug mode and place breakpoints, as well as step through my script, but I can't see the values stored in my table variables.

In the Locals window I see all these variables, but their value is shown as (table):

There is no way to view the content of the variable through the context menu or by clicking on the variable.

I tried to use the Immediate Window to run a query on the table variable, but this seems not to work either.

Any idea how I can get the values from my table variables in the debug session?

回答1:

Whilst I can't find any documetation, anywhere, that explicitly states that you cannot inspect table variables, I don't believe that it's possible. From Transact-SQL Debugger

Locals and Watch. These windows display currently allocated Transact-SQL expressions. Expressions are Transact-SQL clauses that evaluate to a single, scalar expression. The Transact-SQL debugger supports viewing expressions that reference Transact-SQL variables, parameters, or the built-in functions that have names that start with @@. These windows also display the data values that are currently assigned to the expressions.

(My emphasis)

That is, you can only inspect scalars.

As to your attempt to use the Immediate window, the Limitations on Debugger Command and Features says:

The Immediate window is displayed, but you cannot do anything useful with it, such as setting a variable to a value, or querying the database.

---

I've never really used the debugger much - everytime I've looked into it, I encounter limitations like this.

That's why I still tend to use "old-skool"/"printf" approaches to debug SQL - include extra SELECT *s liberally throughout the code showing the current state of tables, and extra PRINT or RAISERROR messages that show other states, etc. And then just run the code normally, until you've bashed it into shape.

回答2:

Using the next code you can see the content of your table as XML.

DECLARE @v XML = (SELECT * FROM <tablename> FOR XML AUTO)

It is useful to check what your SELECT statements return. I tested it and it works.

Read more here.

回答3:

I just simply put in select statements into my script and it displays it to the results window..

select * from @VarTable;

now as I step thru my code and hit the select it will display the values. Then I either comment them out when done testing or set a Testing flag.

Hope this helps

回答4:

Including a select statement in the code is the only way I know and can think of.

Having a 'configuration' table in the database allows adding debugging code permanently to the SP, which helps if you have to debug it often. You can leave code like "if ({select logging level in config table}) = {debug} then select '@variable at location 1' as [@variable at location 1], * from @variable order by {some useful order}".

With the way I include the variable name and possibly the location (if there are several places where you need to check) in both the result and the column name, it makes it easy to tell apart the variables in the output even when a particular table variable has no rows, and you did not expect that.