SQL Debugging Limitations

  • Article

Feature Only in Enterprise Edition   This feature is supported only in Visual C++ Enterprise Edition. For more information, see .

The SQL source code debugger provides many common debugging features. However, some debugger behaviors are not available for SQL debugging. The SQL debugger does not:

  • Debug single SQL statements executed outside of a stored procedure.

  • Support complex breakpoints. Only the location breakpoint is supported.

  • Provide debugging without a Data View. SQL debugging occurs only when a Data View is present in the current workspace. Without an active Data View, there is no debugging.

  • Use SQL memory windows. The memory window is only for the native application. You cannot view what might be thought of as SQL memory.

  • Debug extended stored procedures. Extended stored procedures are actually DLLs that are written in C++ (or any other language) and are not SQL-based.

  • Display registers. The SQL language is interpreted, so there are no registers.

  • Automatically modify cached values. You cannot always expect that changes to locals or parameters that are cached by the SQL interpreter will take effect during the time frame that you’re stepping through an SQL statement. Although you may have modified the value, it may never be checked again. You cannot force a refresh of cached values. Cached values exist because the SQL Server execution plan determines that the values for some variables will not be dynamically loaded for each statement execution or reference. For more information, see "SHOWPLAN Output" in the SQL Server Books Online.

  • Allow realtime modification of stored procedures. During SQL debugging, do not modify a stored procedure. Modification of a stored procedure may produce unpredictable results.