Recommendations for debugging tools to work with SQL Server Express 2019

Question

Recommendations for debugging tools to work with SQL Server Express 2019

Weegee71

SSChasing Mays

Points: 604
More actions
March 15, 2022 at 11:38 am

#3999730

Hi there
I was wondering if anyone knew of debugging toools that work with SQL Server Express 2019
Unfortunately there is no debugger that comes with SQL Server Express 2019, so was wondering if someone
could recommend one.

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply

Grant Fritchey SSC Guru Points: 398882 More actions · Answer 1

I am not a fan of debugging within T-SQL queries, however, if you want to do it, SQL Server Management Studio is free and it does include debugging.

The real question is, what are you trying to get out of the debugger?

"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt

Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning

Phil Parkin SSC Guru Points: 246960 More actions · Answer 2

SSMS v18 and onwards do not appear to have the debugging feature. However, it is still possible to debug T-SQL, but using SSDT as your debug client.

The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin

Grant Fritchey SSC Guru Points: 398882 More actions · Answer 3

Or get the older version. Forgot to mention that.

"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt

Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning

Weegee71 SSChasing Mays Points: 604 More actions · Answer 4

Thanks Phil. I will download SSDT and give that a try

Mr. Brian Gale SSC-Insane Points: 24800 More actions · Answer 5

I agree with Grant here - what are you trying to debug with the debugger?

In general, my "debugging" of SQL scripts is to take the UPDATE, INSERT, or DELETE statements and turn them into SELECTs so I can review what they will be doing. If I need to debug a variable value at a certain point in time, I will just SELECT/PRINT its value out.

I find that the debugging tools in SQL are clunky and I believe they are blocking which is something I usually want to avoid, even on my test/dev systems. Don't want a transaction to get stuck all day because I get called out to help with a more urgent issue and end users or other devs are stuck waiting for my query to complete so they can use the table! And in the event it is not a blocking thing (like I said, I never use the debugger), if I tossed my query into a transaction, that can eat up a lot of resources if I leave transaction open over a weekend by accident (for example). For SQL debugging, I like the "run a small chunk and verify results" OR the "SELECT/PRINT to review variable values at a specific point in time" approach.

The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.