Describes how to debug an SQL Server Object in an ASP. NET program.

Debugging SQL Server objects in ASP. NET programs. Direct debugging in databases allows us to directly debug stored procedures in Visual Studio IDE. However, sometimes we need to debug the stored procedure when the ASP. NET program calls it. In this way, when a database object is called, we can debug it.

This debugging method is integrated into application debugging. To use it, perform the following steps:
◆ Add breakpoints to the database objects you want to debug. Database objects can be debugged only when breakpoints are contained. For example, when an application calls a stored procedure, you cannot enter the stored procedure. If you want to debug the stored procedure, you must set a breakpoint in the stored procedure.
◆ Configure the application so that it can debug the SQL Server Object. This is easy. You only need to select a check box.
◆ Disable the connection pool. The connection pool can improve performance. It allows a program to connect to a database using an idle connection in the connection pool. If it is enabled, debugging cannot be performed correctly. Because the connection pool is enabled by default, We must disable it when setting the connection string. After debugging SQL Server objects in ASP. NET programs, remember to re-enable the connection pool)

Next, let's take a look at the specific steps.

First, open the "DoThings" Stored Procedure in Visual Studio and set a breakpoint in the sentence "DECLARE @ avgpice money. This completes the first step and the second step.

Configure the ASP. NET Program to support SQL Server debugging. Right-click the project and select Properties. A dialog box is displayed, as shown in. Select the start option and select the SQL Server check box in the debugger section. This completes the first two steps.

In the last step, we need to modify the connection string to disable the connection pool. This task is quite simple. You only need to add the attribute "Pooling = false" after your connection string. Suppose you have defined the connection string information in the & lt; connectionString> node of Web. config, the modified connection string is as follows:

 
 

  
  
<connectionStrings> 
  
  
<add name="NorthwindConnectionString" connectionString="Data Source=.\
SQLEXPRESS;AttachDbFilename=|DataDirectory|\NORTHWND.MDF;Integrated 
Security=True;User Instance=True; Pooling=false" providerName="System.
Data.SqlClient"/> 
  
  
</connectionStrings>  
 
 

Now, we have completed these three steps. To demonstrate how to debug, create an ASP. NET page that calls the "DoThings" stored procedure. The Demo you downloaded at the end of this article contains this page. When you debug an ASP. NET program and access this page, the program will suspend the place where breakpoints are set during the stored procedure. Then, you can execute the stored procedure in one step, and view and modify the values of parameters and variables in the invigilation window, just like directly debugging the stored procedure in the database.

In versions earlier than SQL Server, there was a set of independent tools for debugging stored procedures. In SQL Server 2005, stored procedures, triggers, and UDFs are all debugged Through Visual Studio Team System and Professional. It brings us three ways to debug SQL Server: Direct debugging in the database, application debugging, and debugging in the SQL Server project. In this article, we have studied the first two debugging methods to use the local database ). The preceding section describes how to debug an SQL Server Object in an ASP. NET program.

1. ASP. NET calls the WCF Service
2. Analysis of ASP. NET verification controls
3. Compatibility between the WCF Service and ASMX service in ASP. NET
4. ASP. NET Applications
5. ASP. NET HttpModule