March 15, 2022 at 11:38 am
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.
March 15, 2022 at 12:47 pm
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
March 15, 2022 at 1:02 pm
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
You can lead a horse to water, but a pencil must be lead.
Stan Laurel
March 15, 2022 at 1:10 pm
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
March 15, 2022 at 2:10 pm
Thanks Phil. I will download SSDT and give that a try
March 15, 2022 at 3:40 pm
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.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply