SQL and Mixed-Language Debugging
If you are planning to debug a mixed-language project, read the following considerations:
- Database Requirements
- Enabling SQL Debugging for Mixed Language Projects
- Connecting to a Database
- SQL Debugging and Running Applications
- T-SQL and Managed or Unmanaged Code
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.
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.
To enable SQL debugging
- In Solution Explorer, select the project.
- From the View menu, click Property Pages.
The <Project> Property Pages dialog box appears.
- In the Configuration drop-down list box (at the top of the Property Pages dialog box), choose Debug.
- Under the Configuration Properties folder in the left pane, click the Debug or Debugging category (depending on the language of the project).
- In the properties grid to the right, set the SQL Debugging option to Yes.
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.
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.
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.