Once deployed, your SQL CLR stored
procedures, functions, triggers, aggregates, and UDTs, and their
dependencies, might become difficult to keep track of in your head.
Luckily, you can easily perform discovery on deployed SQL CLR entities using the SSDT and SSMS UIs. All SQL CLR objects in a database can be found in the Object Explorer
window in SSMS and the SQL Server Object Explorer window in Visual
Studio. To find them within either window’s tree view, first navigate
to the \servername\Databases\databasename node (where servername and databasename are the names of your server and database, respectively). Refer to Table 1 for the subnodes of this node that contain each SQL CLR entity.
Table 3-1. Finding CLR Objects in the Object Explorers.
To View… | Look in… |
|---|
Parent node for SQL CLR stored procedures, database-level DDL triggers, functions, aggregates, and UDTs | Programmability (see Figure 1) |
Assemblies | Programmability\Assemblies (see Figure 2) |
Stored procedures | Programmability\Stored Procedures (see Figure 3) |
Functions | Programmability\Functions\Scalar-Valued Functions and Programmability\Functions\Table-Valued Functions (see Figure 4) |
Aggregates | Programmability\Functions\Aggregate Functions (see Figure 4) |
DML triggers | Tables\tablename\Triggers, where tablename is the name of the database table, including the schema name, on which the trigger is defined (see Figure 5) |
DDL triggers | Programmability\Database Triggers (see Figure 6) (also, for server-level triggers, \servername\Server Objects\Triggers, where servername is the name of your server) |
UDTs | Programmability\Types\User-Defined Types (see Figure 7 – in the SQL Server Object Explorer in Visual Studio, the node is labeled “User-Defined Types (CLR)”) |
Bear
in mind that in SSMS, you might need to use the Refresh shortcut menu
option on the nodes listed in the table to see your SQL CLR objects. If
you’ve deployed or deleted any SQL CLR objects (as will be discussed
shortly) since opening the Object Explorer
connection to your database, the tree view will be out of date and will
need to be refreshed. Notice that the tree view icons for SQL CLR stored procedures and SQL CLR DML triggers differ slightly from their T-SQL counterparts—they have a small yellow padlock on the lower-right corner.
In
SSMS, once you’ve located a SQL CLR entity in the Object Explorer
window, you can right-click its tree view node and generate CREATE, DROP, and in some cases, ALTER scripts for it by selecting the Script object type As option from the shortcut menu (where object type
is the SQL CLR object type selected). The script text can be inserted
into a new query window, a file, or the clipboard, or it can be used to
create a SQL Server Agent job. In the Visual Studio SSDT Object
Explorer, double-clicking a CLR assembly’s or a CLR entity’s tree view
node opens up a T-SQL Editor window with the object’s CREATE script code inside.
Back in SSMS, for stored procedures, you can generate EXECUTE
scripts or, by selecting Execute Stored Procedure from the shortcut
menu, execute stored procedures interactively and generate the
corresponding script via the SSMS Execute
Procedure dialog box. This dialog box explicitly prompts you for all
input parameters defined for the stored procedure. In addition to
generating scripts for your SQL CLR entities,
you can view their dependencies (either objects that are dependent on
them or objects on which they depend). Just right-click the object, and
then choose the View Dependencies option from the shortcut menu.
To
remove your SQL CLR objects, either in preparation for loading a new
version of your assembly or to delete the objects permanently, you have
several options. For Visual Studio SQL Server Database Project
assemblies, redeploying one causes Visual Studio to drop it and any SQL
CLR objects within it that had been previously deployed with it by
Visual Studio. This means that new versions can be deployed from Visual
Studio without any preparatory steps.
For Class Library projects, you must issue T-SQL DROP
commands for each of your SQL CLR objects and then for the assembly
itself. You must drop any dependent objects before you drop the SQL CLR
entity. For example, you must drop tblPoint before dropping typPoint. You can write these DROP scripts by hand or generate them by using the Script object type As/DROP To shortcut menu options in the SSMS Object Explorer window.
You
can also use the Delete shortcut menu option on any SQL CLR object to
drop it. In the SSDT SQL Server Object Explorer, this option displays
the Preview Database Updates window, which provides a preview of all
changes along with Generate Script and Update Database buttons. This is
shown in Figure 8.
With
the SSDT delete option, all dependent objects will be deleted first, in
the appropriate order. For example, deleting the assembly through SSDT
would drop each CLR entity first.
In SSMS, the Delete shortcut
menu option drops only a single object. Clicking it displays the Delete
Object dialog box, shown in Figure 9.
To compensate for the lack of a dependency object deletion feature comparable to that provided by SSDT, the script file Cleanup.sql in the SSMS project provided with the sample code contains all the necessary DROP
commands, in the proper order, for removing all traces of your Visual
Studio SQL Server Database project or Class Library project assembly
from the AdventureWorks2012
database. For the Class Library project, run the script before you
deploy an updated version of your assembly or, if you want to, use the
script to permanently remove the assembly and its SQL CLR entities.
Note
Cleanup.sql also removes tables tblAggregateTest and tblPoint, which are created by the scripts CreateTblAggregateTest.sql and CreateTblPoint.sql, respectively.
