This editorial was originally published on Jan 16, 2015. It is being republished as Steve is traveling.

One of the tools that I found useful early in my development career was the debugger. Being able to track the values of variables, check the call stack, and pause execution of programs was handy. Early in my career, the tools were very rudimentary, but the latest debuggers in Visual Studio are quite advanced. I remember using a great debugger in Rapid/SQL years ago that helped me with some SQL Server 2000 code.

There are debugging tools included with SQL Server, but the last time I used them, they seemed to be a bit flaky. However the need to follow your code slowly along it's execution plan hasn't changed. I'm curious this week, what many of you do inside of SQL Server to debug your code. I wanted to ask you this week:

How do you debug your applications that work with SQL Server?

These could be .NET applications that query the database. You could have ETL processes using SSIS or some other tool that you work on. Perhaps you have a system that runs entirely inside SQL Server and you need to untangle your T-SQL.

Do you use Visual Studio tools? Have you configured the T-SQL debugger? Are you a PRINT statement or temp-table-for-results developer? Perhaps you have logging or some other mechanism that you use?

Let us know this week what works well for you, and if you've found a particular technique to be handy in a situation, we'd love an article that might teach someone else how to debug their code.