Export (0) Print
Expand All
This topic has not yet been rated - Rate this topic

SQL and Mixed-Language Debugging

Visual Studio .NET 2003

If you are planning to debug a mixed-language project, read the following considerations:

Database Requirements

With Visual Studio .NET, you can debug mixed-language applications that make connections to databases and execute SQL stored procedures. To do this, the applications must connect to the databases using one of the following:

  • OLE DB, ODBC, or DBLIB.
  • A technology such as ADO that is built on top of OLE DB, ODBC, or DBLIB.
  • The managed data adapter for SQL Server.

Setup

The application that calls SQL can run on your local machine or run remotely. To debug a remote application, you must run the proper setup on the remote machine.

The SQL Server can run on the same machine as the application or on a remote machine. The machine where SQL Server runs must have the proper SQL debugging components. Running the SQL Server setup program with the proper options will install the SQL debugging components. To make sure you have the latest version of the components, however, you should run the Server Setup from Visual Studio .NET Setup. For more information, see SQL Debugging Components.

Enabling SQL Debugging for Mixed Language Projects

To enable SQL debugging

  1. In Solution Explorer, select the project.
  2. From the View menu, click Property Pages.

    The <Project> Property Pages dialog box appears.

  3. In the Configuration drop-down list box (at the top of the Property Pages dialog box), choose Debug.
  4. Under the Configuration Properties folder in the left pane, click the Debug or Debugging category (depending on the language of the project).
  5. In the properties grid to the right, set the SQL Debugging option to Yes.

Connecting to a Database

Before debugging a SQL mixed-language application, you must establish a connection to the database your application is going to interact with. For more information, see Accessing and Initializing Server Explorer. You can then open the stored procedures that your application is going to execute and set up breakpoints.

After this, you can debug as you would any other application. When the application executes you will then be able to hit breakpoints in managed code (C#, Visual Basic, or Managed Extensions for C++) or native code (C++) as well as T-SQL source. You can then view and modify the values of incoming parameters and local variables, step into other stored procedures, and perform other debugging procedures just as you would when debugging stored procedures directly.

For more information, see Debugging SQL Stored Procedures and Walkthrough: Debugging Hello World, a SQL Stored Procedure.

SQL Debugging and Running Applications

You can do SQL debugging after attaching to a running application. Note, however, that only the database connections that you have created after you have completed the attach can be debugged.

T-SQL and Managed or Unmanaged Code

You cannot step into T-SQL from managed or native code or into managed or native code from T-SQL. To get around this limitation, set a breakpoint in your SQL code. You can also use Run to Cursor to reach a desired point, without using a breakpoint.

See Also

Debugging SQL

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.