Limitations on Debugger Commands and Features

  • Article

This topic applies to:

Edition

Visual Basic

C#

C++

Web Developer

Express

 Topic does not apply Topic does not apply Topic does not apply Topic does not apply

Standard

 Topic does not apply Topic does not apply Topic does not apply Topic does not apply

Pro and Team

 Topic applies Topic applies Topic applies Topic applies

Table legend:

Topic applies

Applies
Topic does not apply

Does not apply
Topic applies but command hidden by default

Command or commands hidden by default.

The SQL debugger provides many but not all common debugging features. SQL debugging supports most debugger commands, such as setting breakpoints and stepping. You can view the values of variables and passed parameters in the Locals window. You can also drag expressions to the Watch window to track them as you step through or run the procedure.

However, debugging SQL happens in a very different environment, due to some basic characteristics of SQL Server itself. Some debugging limitations apply only to T-SQL debugging, or to SQL CLR debugging. Other limitations apply to all SQL debugging.

General Limitations on SQL Debugging

  • You cannot use Edit and Continue.

  • You cannot use Run to Cursor in the Call Stack window.

  • You cannot use Break while a SQL statement is processing.

  • The output of SQL PRINT statements does not appear in the debugger or the Database Output pane.

  • You cannot use AutoRollback in Visual Studio. If you reproduce a bug that changes data, you can lose the bug because your data has changed.

  • A number of windows either are not available or do not provide any capability. They are:

    • Memory

    • Registers

    • Disassembly for T-SQL

T-SQL Debugging Limitations

  • Breakpoint conditions and filters are not supported.

  • Because SQL does not have true memory or registers, you cannot use the Memory window or Registers window.

  • You cannot use Set Next Statement to change the execution sequence. You must follow the flow control and statement order in the SQL code. As a workaround, you can put control statements around blocks of SQL code and change variable values.

  • You cannot access any .NET Framework variables or properties from inside a T-SQL object.

  • The Immediate window is displayed, but you cannot do anything useful with it, such as setting a variable to a value, or querying the database.

  • A number of windows either are not available or do not provide any capability. They are:

    • Disassembly

    • Threads

    • Registers

    • Processes

    • Modules

SQL CLR Debugging Limitations

  • Only one SQL CLR debug session can occur per server, because all SQL CLR code execution freezes while any SQL CLR debugging happens. Because of this, the debugger user is required to be a SQL system administrator in order to do SQL CLR debugging.

  • SQL CLR debugging should never be done on a production server. SQL CLR debugging is risky: the SQL CLR debugger can read and write process memory, and can execute arbitrary code in the server process. It causes all managed threads on the server to be stopped. And when you terminate a debugging session, SQL Server can halt.

  • You cannot access global SQL variables such as @@ROWCOUNT when inside a CLR SQL object.

  • In a Visual Studio SQL Server project, you can only add references to a subset of the .NET Framework class libraries. Not all assemblies can be referenced.

See Also

Concepts

SQL Debugging Limitations

Debugging SQL