Can we get the T-SQL debugger back?

Question

How can I browbeat Microsoft to re-enable the debugger in SSMS? I tried using SSDT in Visual Studio 2022, and it was absurd ... I had to spend fifteen minutes creating a new project, importing the database, etc. only to be told, when I started trying to debug a stored procedure, that "Only one statement is allowed per batch" .... this despite setting the "Build Action" property on the stored procedure to "None" (something that I should not have to do in the first place, IMHO).

For the record, this is a very intricate stored procedure with nearly 600 lines of T-SQL code.

This requirement to use SSDT may be fine for developers who spend their whole lives in Visual Studio, but for database administrators that have to debug an errant stored procedure or function because the sales team is shrieking from the rooftops about economic devastation if their stuff isn't fixed RIGHT NOW? It's worse than useless, because it is a gigantic time suck that ... well, doesn't work the way we need it to.

In addition, the fact that SSMS is now version-specific (i. e. if I have to debug a stored procedure in a SQL 2019 instance, I have to fire up SSMS 18.x to script it out, then copy/paste into SSMS 17.9.1 or earlier to be able to step through it ... and now, with SQL 2022 rolling out throughout the company, I now have to install SSMS 19 to be able to perform these tasks.

Whose head do I need to jam into a toilet to make this happen?

Answer 1

Hi @David Naples,

This is the most requested feature "Put debugger back to SSMS" for MS SQL Server.

Please go ahead and up-vote that request: https://feedback.azure.com/d365community/idea/acd874a4-6125-ec11-b6e6-000d3a4f0da0

Answer 2

While this is the most voted-on item on the feedback site, I would not hold my breath. I believe there are sound technical reasons for not having the debugger in SSMS. For one thing, I believe the debugger calls back to your machine on port 135, which means that you have to open that sensitive port in your firewall. OK, if the SQL Server instance is local on your machine, that's not an issue, but then this means you can only debug in specific situations.

I think the last time I used an SQL debugger was in 2004. I realised that every time I wanted to use the debugger, I spent more time on getting it to work than I gained in productivity. Since then, I have found that debug SELECT and PRINT works very well for me. I would say even better, because how do you inspect a temp table or a table variable from the debugger?

Answer 3

Hi @David Naples

I have only been with SQL Server for almost a year. I have not used T-SQL debugger.

In your description, I can see your troubles. But whether to add the T-SQL debugger back is a matter for the official to decide.

The thing that can be done is to continue to give feedback to the official.

Best regards,

Percy Tang

Answer 4

See https://techcommunity.microsoft.com/t5/sql-server-blog/sql-server-management-studio-ssms-19-0-released/bc-p/3732230/highlight/true#M2221

Erin statet out: "We are very aware of the feedback item to which you linked, and we definitely appreciate the value of the T-SQL debugger in certain circumstances. However, it is an extremely expensive component to maintain in two separate tools (Visual Studio and SSMS). ...
we decided to make some practical choices with the current debugger technology to not continue that forward in SSMS and rely on Visual Studio instead. We did work with the appropriate teams at MS to ensure there is access to a free version of Visual Studio that includes the T-SQL debugger."

Answer 5

On the other hand, there's still a bug in the SQL debugger: https://developercommunity.visualstudio.com/t/VS2022-SQL-debugging---buggy-command-lin/10331453

If you like, vote it up.