title

titleSuffix

description

author

ms.author

ms.reviewer

ms.date

ms.service

ms.subservice

ms.topic

helpviewer_keywords

monikerRange

Transact-SQL debugger

T-SQL debugger

Learn how to step through code and view the execution state using the Transact-SQL debugger, and how to do various other debugging tasks.

markingmyname

maghan

drskwier

10/16/2021

sql

ssms

conceptual

Transact-SQL debugger, introduction

>= sql-server-2016

Transact-SQL debugger

[!INCLUDE SQL Server]

The [!INCLUDEtsql] debugger helps you find errors in [!INCLUDEtsql] code by investigating the run-time behavior of the code. After you set the [!INCLUDEssDE] Query Editor window to debug mode, you can pause execution on specific lines of code and inspect information and data that is used by or returned by those [!INCLUDEtsql] statements.

[!INCLUDEssms-old-versions] T-SQL debugging is also available in SQL Server Data Tools for Visual Studio.

Stepping through Transact-SQL Code

The [!INCLUDEtsql] debugger provides the following options that you can use to navigate through [!INCLUDEtsql] code when the [!INCLUDEssDE] Query Editor window is in debug mode:

Set breakpoints on individual [!INCLUDEtsql] statements.

A breakpoint specifies a point at which you want execution to pause so you can examine data. When you start the debugger, it pauses on the first line of code in the Query Editor window. To run to the first breakpoint that you have set, you can use the Continue feature. You can also use the Continue feature to run to the next breakpoint from any location at which the window is currently paused. You can edit breakpoints to specify actions such as the conditions under which the breakpoint should pause execution, information to print to the output window, and change the location of the breakpoint.
Step into the next statement.

This option enables you to navigate through a set of statements one by one, and to observe their behavior as you go.
Step either into or over a call to a stored procedure or function.

If you're sure there are no errors in a stored procedure, you can step over it. The procedure is executed in full, and the results are returned to the code.

If you want to debug a stored procedure or function, you can step into the module. SQL Server Management Studio opens a new [!INCLUDEssDE] Query Editor window that is populated with the source code for the module, places the window into debug mode, and then pauses execution on the first statement in the module. You can then navigate through the module code, for example, by setting breakpoints or stepping through the code.

For more information about how the debugger enables you to navigate code, see Step Through Transact-SQL Code.

Viewing debugger information

Each time the debugger pauses execution on a specific [!INCLUDEtsql] statement, you can use the following debugger windows to view the current execution state:

Locals and Watch. These windows display currently allocated [!INCLUDEtsql] expressions. Expressions are [!INCLUDEtsql] clauses that evaluate to a single, scalar expression. The [!INCLUDEtsql] debugger supports viewing expressions that reference [!INCLUDEtsql] 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.
QuickWatch. This window displays the value of a [!INCLUDEtsql] expression, and enables saving that expression to a Watch window.
Breakpoints. This window displays the currently set breakpoints and enables you to manage them.
Call Stack. This window displays the current execution location. And also provides information about how execution passed from the original Query Editor window through any functions, stored procedures, or triggers to reach the current execution location.
Output. This window displays various messages and program data, such as system messages from the debugger.
Results and Messages. These tabs on the Query Editor window display the results of previously executed [!INCLUDEtsql] statements.