CLR Procedure Not list in processes SQL Server - sql

Question

I created a CLR procedure to download email files. It works perfectly, the problem that when it is running it is not listed when I query the server processes.
Does anyone know a way to get it in sql server processes?
I'm using the query below
exec dbo.sp_download_files_mail

Answer 1

If you are expecting to see exec dbo.sp_download_files_mail in sys.dm_exec_sql_text via the sys.dm_exec_requests.plan_handle, then that's probably not going to happen. When you use EXEC it creates a sub-process that is probably a different execution plan. In the case of SQLCLR, SQL Server has no insight into what is happening unless you are executing T-SQL using SqlConnection, and then you will get the plan for the SQL being executed within the SQLCLR object and not the plan for the SQLCLR object itself. When you are executing a SQLCLR object and it is not executing any T-SQL statements, then both the sql_handle and plan_handle values are empty: 0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.
However, you can see the SQLCLR object showing up in the plan_handle value coming back from sys.dm_exec_cached_plans. The SQLCLR object does seem to appear in this DMV upon being executed, but as this DMV reports cached objects, it does not necessarily get removed once the SQLCLR object completes. Hence, you can't use this DMV to indicate current running status of the object. Nor does the plan_handle value reported in sys.dm_exec_cached_plans show up in sys.dm_exec_requests while it is running.
You can test this behavior yourself by creating a SQLCLR Stored Procedure or SQLCLR scalar User-Defined Function that does nothing more than call System.Threading.Thread.Sleep() for at least 30 seconds. If you do not want to deal with creating this, a pre-made SQLCLR UDF – DB_WaitForDelay – exists in the Free version of the SQL# SQLCLR library (that I created) and is what I used in the example code below.
In SQL Server Management Studio (SSMS), open up two query tabs and paste in the following:
TAB 1
EXEC [SQL#].[DB_WaitForDelay] 30000, 1;
TAB 2
SELECT txt.*, req.*
FROM sys.dm_exec_requests req
OUTER APPLY sys.dm_exec_sql_text(req.[plan_handle]) txt
WHERE req.[session_id] = <session_id_of_Tab1>;
DBCC INPUTBUFFER(<session_id_of_Tab1>);
SELECT txt.*, cp.*
FROM sys.dm_exec_cached_plans cp
OUTER APPLY sys.dm_exec_sql_text(cp.[plan_handle]) txt
WHERE cp.[cacheobjtype] LIKE N'CLR%';
Once you have replaced the two instances of "<session_id_of_Tab1>" in the Tab 2 query, execute the Tab 1 query, then go back to Tab 2 and execute that batch of queries.
IF you really need to know if this SQLCLR object is executing as it is executing, then you will have to do something along the lines of using SqlConnection with a ConnectionString of Context Connection = true; and then execute (at the beginning of the SQLCLR object) something like SET CONTEXT_INFO 0x1234; (assuming that you are not already using CONTEXT_INFO for something else). At the end of the SQLCLR object, execute a 2nd SqlCommand for SET CONTEXT_INFO 0x00; to clear it out.
This approach allows you to use the following query to confirm that it is currently running:
SELECT req.*
FROM sys.dm_exec_requests req
WHERE req.[context_info] = 0x1234;
Also, it is a rather bad practice to prefix Stored Procedure names with sp_ as that causes SQL Server to first check in [master] for the object and then the current Database. Using something like spDownloadEmailFiles is better, though still no real good reason to prefix Stored Procedure / Function / Table / View names with anything.