To debug a SQL CLR user-defined scalar function 1. In a new SQL Server project, establish a connection to the AdventureWorks sample database. For more information, see How to: Connect to a Database . 2. Create a new function using the code from the first example section below, and name it OrderCount.cs. For more information, see How to: Develop with the SQL Server Project Type . 3. Add a script that tests the function by including it in a SELECT statement. In Solution Explorer, right-click the TestScripts directory, click Add Test Script, and insert the code from the second Example section below. Save the file with the name CallOrderCount.sql. Right-click the file name, and choose Set as Default Debug Script. 4. Place a breakpoint in OrderCount.cson the line that instantiates a SqlCommand, and then on the Debug menu, click Start to compile, deploy, and unit-test the project. When the instruction pointer, designated by a yellow arrow, appears on the breakpoint, you are debugging your function. 5. Try out different debugging features. 1. Step past the statement instantiating the SqlCommand using Step Into from the Debug menu. 2. In the Locals window, open the variable sqlComm, which is a SqlCommand, and examine its members. 3. Click Step Into on the Debug menu to step one line in the function. Note that the member sqlComm.CommandText has been instantiated. 4. In the Text Editor, drag sqlComm to any location in the Watch window. The variable is now added to the list of watched variables. 5. Choose Step Into again, and note that a new window labeled Dynamic T- SQL opens, displaying the SQL statement that is about to be executed. 6. Choose Step Into to execute the statement and return to the function. 7. Press Continue again, and note the second Dynamic T-SQL window that opens, showing the code that returns the value of the function. 8. Press Continue again to finish debugging the function. Example This is the code required to create the function. using System; using System.Data.SqlClient; using Microsoft.SqlServer.Server; public partial class UserDefinedFunctions { [Microsoft.SqlServer.Server.SqlFunction(DataAccess = DataAccessKind.Read)] public static int OrderCount() { using (SqlConnection conn = new SqlConnection("context connection=true")) { conn.Open(); SqlCommand cmd = new SqlCommand(); cmd.Connection = conn; cmd.CommandText = "SELECT 42"; //cmd = new SqlCommand("SELECT 42",conn); int result = (int)cmd.ExecuteScalar(); return result; } } }; This is the test script that calls the function. SELECT dbo.OrderCount() This example shows how to debug a SQL CLR User Defined Table-Valued Function (UDF). Note: The dialog boxes and menu commands you see might differ from those described in Help depending on your active settings or edition. To change your settings, choose Import and Export Settings on the Tools menu. For more information, see Visual Studio Settings . To debug a SQL CLR user-defined table-valued function 1. In a new SQL Server Project, establish a connection to a database. For more information, see How to: Connect to a Database . 2. Create a new function using the code from the first example section below and name it TableOfPrimes.cs. For more information, see How to: Develop with the SQL Server Project Type . 3. Add a script that tests the function by including it in a SELECT statement. In Solution Explorer, right-click the TestScripts directory, click Add Test Script, and insert the code from the second of the following Example sections. Save the file with the name TestPrime.sql. Right-click the file name, and click Set as Default Debug Script. 4. Set breakpoints in TableOfPrimes.cs, and then on the Debug menu, click Start to compile, deploy, and unit test the project. When the instruction pointer, designated by a yellow arrow, appears on a breakpoint, you are debugging the SQL CLR code. 5. Try out different debugging features. 1. On the Debug menu, click Step Into repeatedly to observe line-by-line execution of the function. 2. As you step through the function, you can use the Locals and Watch windows to observe the values of different members. 3. Click Continue again to finish debugging the function. 4. In the Output window, select Database Output from the Show output from drop-down list, and you can observe the results of executing the two queries in the TestPrimes.sql script. This example shows how to debug a SQL CLR User Defined Function (UDF). It creates a new SQL CLR User-Defined Function in the AdventureWorks sample database. Note: The dialog boxes and menu commands you see might differ from those described in Help depending on your active settings or edition. To change your settings, choose Import and Export Settings on the Tools menu. For more information, see Visual Studio Settings . This example shows how to debug a SQL CLR user-defined type. It creates a new SQL CLR type in the AdventureWorks sample database. The type is then used in a table definition, an INSERT statement, and then a SELECT statement. Note: The dialog boxes and menu commands you see might differ from those described in Help depending on your active settings or edition. To change your settings, choose Import and Export Settings on the Tools menu. For more information, see Visual Studio Settings . To debug a CLR SQL user-defined type 1. In a new SQL Server project, establish a connection to the AdventureWorks sample database. For more information, see How to: Connect to a Database . 2. Create a new type using the code from the first example section below, and name it Point.cs. For more information, see How to: Develop with the SQL Server Project Type . 3. Add a script that tests the type. In Solution Explorer, right-click the TestScripts directory, click Add Test Script, and insert the code from the second Example section below. Save the file with the name Point.sql. Right-click the file name, and click Set as Default Debug Script. 4. Add breakpoints. 1. In the Types folder in Server Explorer, open Point. 2. Place a breakpoint inside each method so you can observe the flow of control inside the type. 5. From the Debug menu, choose Start to compile, deploy, and unit test the project. When the instruction pointer, designated by a yellow arrow, appears on the breakpoint, you are debugging your function. 6. Try out different debugging features. 1. The Parse method is executed once for each INSERT statement in the script in Point.sql. By repeatedly clicking Step Into on the Debug menu, you can watch how the method converts a colon-delimited number pair into a Point object. 2. In the Locals window, open the variable pt, which contains the current Point being built. 3. In the Text Editor, double-click the pt variable to select it. Drag pt to any location on the Watch window. pt is now added to the list of watched variables, and you can observe it as the Point is built. 4. Step through the class several times and observe the differences between the path an INSERT and a SELECT take. 5. Press Continue again to finish debugging the function. Example This is the code defining the type used in this sample. This code creates a table named Points, inserts rows into it, and prints out the table contents. Note that you do not have to include the batch command GO between creating the table and accessing it. In fact Visual Studio 2005 will interpret the GO as an invalid SQL command. using System; using System.Data.Sql; using System.Data.SqlTypes; using System.Runtime.Serialization; [Serializable, SqlUserDefinedTypeAttribute(Format.Native)] public struct Point: INullable { } This is the test script that calls the function. CREATE TABLE dbo.Points ( ID int IDENTITY(1,1) PRIMARY KEY, Pnt Point) INSERT INTO dbo.Points (Pnt) VALUES (CONVERT(Point, '3:4')) INSERT INTO dbo.Points (Pnt) VALUES (CONVERT(Point, '-1:5')) INSERT INTO dbo.Points (Pnt) VALUES (CAST ('1:99' AS Point)) SELECT ID, Pnt.ToString() as StringPoint, Pnt.X as X, Pnt.Y as Y FROM dbo.Points You can debug an existing SQL CLR stored procedure by using direct database debugging, the same way you would debug a T-SQL procedure. However, that will not work if you need to create or modify a SQL CLR procedure, because you need to compile and deploy it. These steps that do not exist for the T-SQL procedure. In this case, you need to create a SQL Server project in Visual Studio. The following task creates a new SQL CLR stored procedure in the Adventureworks database, one of the databases installed with SQL Server 2005, and then shows how to debug it. You create a stored procedure that adds a new currency to the Sales.Currency table. This example focuses on debugging within a SQL Server project. Once you have created the stored procedure, you can debug it using direct database debugging. For more information, see How to: Step into an Object Using Server Explorer . Note: The dialog boxes and menu commands you see might differ from those described in Help depending on your active settings or edition. To change your settings, choose Import and Export Settings on the Tools menu. For more information, see Visual Studio Settings . To debug a SQL CLR stored procedure 1. In a new SQL Server project, establish a connection to the AdventureWorks sample database. For more information, see How to: Connect to a Database . 2. Create a new stored procedure using the code from the first example section that follows, and name it InsertCurrency.cs. For more information, see How to: Develop with the SQL Server Project Type .