Tutorial :Query times out in .Net SqlCommand.ExecuteNonQuery, works in SQL Server Management Studio


Update: Problem solved, and staying solved. If you want to see the site in action, visit Tweet08

I've got several queries that act differently in SSMS versus when run inside my .Net application. The SSMS executes fine in under a second. The .Net call times out after 120 seconds (connection default timeout).

I did a SQL Trace (and collected everything) I've seen that the connection options are the same (and match the SQL Server's defaults). The SHOWPLAN All, however, show a huge difference in the row estimates and thus the working version does an aggressive Table Spool, where-as the failing call does not.

In the SSMS, the datatypes of the temp variables are based on the generated SQL Parameters in the .Net, so they are the same.

The failure executes under Cassini in a VS2008 debug session. The success is under SSMS 2008 . Both are running against the same destination server form the same network on the same machine.

Query in SSMS:

DECLARE @ContentTableID0 TINYINT  DECLARE @EntryTag1 INT  DECLARE @ContentTableID2 TINYINT  DECLARE @FieldCheckId3 INT  DECLARE @FieldCheckValue3 VARCHAR(128)  DECLARE @FieldCheckId5 INT  DECLARE @FieldCheckValue5 VARCHAR(128)  DECLARE @FieldCheckId7 INT   DECLARE @FieldCheckValue7 VARCHAR(128)  SET @ContentTableID0= 3  SET @EntryTag1= 8  SET @ContentTableID2= 2  SET @FieldCheckId3= 14  SET @FieldCheckValue3= 'igor'  SET @FieldCheckId5= 33  SET @FieldCheckValue5= 'a'  SET @FieldCheckId7= 34  SET @FieldCheckValue7= 'a'    SELECT COUNT_BIG(*)  FROM dbo.ContentEntry AS mainCE  WHERE GetUTCDate() BETWEEN mainCE.CreatedOn AND mainCE.ExpiredOn  AND (mainCE.ContentTableID=@ContentTableID0)  AND ( EXISTS (SELECT *                FROM dbo.ContentEntryLabel                WHERE ContentEntryID = mainCE.ID                AND GetUTCDate() BETWEEN CreatedOn AND ExpiredOn                AND LabelFacetID = @EntryTag1))        AND (mainCE.OwnerGUID IN (SELECT TOP 1 Name                                  FROM dbo.ContentEntry AS innerCE1                                  WHERE GetUTCDate() BETWEEN innerCE1.CreatedOn AND innerCE1.ExpiredOn                                  AND (innerCE1.ContentTableID=@ContentTableID2                                       AND EXISTS (SELECT *                                                   FROM dbo.ContentEntryField                                                   WHERE ContentEntryID = innerCE1.ID                                                   AND (ContentTableFieldID = @FieldCheckId3                                                        AND DictionaryValueID IN (SELECT dv.ID                                                                                  FROM dbo.DictionaryValue AS dv                                                                                  WHERE dv.Word LIKE '%' + @FieldCheckValue3 + '%'))                                                  )                                      )                                 )             OR EXISTS (SELECT *                        FROM dbo.ContentEntryField                        WHERE ContentEntryID = mainCE.ID                        AND (   (ContentTableFieldID = @FieldCheckId5                                 AND DictionaryValueID IN (SELECT dv.ID                                                           FROM dbo.DictionaryValue AS dv                                                           WHERE dv.Word LIKE '%' + @FieldCheckValue5 + '%')                                )                             OR (ContentTableFieldID = @FieldCheckId7                                 AND DictionaryValueID IN (SELECT dv.ID                                                           FROM dbo.DictionaryValue AS dv                                                           WHERE dv.Word LIKE '%' + @FieldCheckValue7 + '%')                                 )                            )                       )            )  

Trace's version of .Net call (some formatting added):

exec sp_executesql N'SELECT COUNT_BIG(*) ...'  ,N'@ContentTableID0 tinyint  ,@EntryTag1 int  ,@ContentTableID2 tinyint  ,@FieldCheckId3 int  ,@FieldCheckValue3 varchar(128)  ,@FieldCheckId5 int  ,@FieldCheckValue5 varchar(128)  ,@FieldCheckId7 int  ,@FieldCheckValue7 varchar(128)'  ,@ContentTableID0=3  ,@EntryTag1=8  ,@ContentTableID2=2  ,@FieldCheckId3=14  ,@FieldCheckValue3='igor'  ,@FieldCheckId5=33  ,@FieldCheckValue5='a'  ,@FieldCheckId7=34  ,@FieldCheckValue7='a'  


It is not your indexes.

This is parameter-sniffing, as it usually happens to parametrized stored procedures. It is not widely known, even among those who know about parameter-sniffing, but it can also happen when you use parameters through sp_executesql.

You will note that the version that you are testing in SSMS and the version the the profiler is showing are not identical because the profiler version shows that your .Net application is executing it through sp_executesql. If you extract and execute the full sql text that is actually being run for your application, then I believe that you will see the same performance problem with the same query plan.

FYI: the query plans being different is the key indicator of parameter-sniffing.

FIX: The easiest way to fix this one assuming it is executing on SQL Server 2005 or 2008 is to add the clause "OPTION (RECOMPILE)" as the last line of you SELECT statement. Be forewarned, you may have to execute it twice before it works and it does not always work on SQL Server 2005. If that happens, then there are other steps that you can take, but they are a little bit more involved.

One thing that you could try is to check and see if "Forced Parameterization" has been turned on for your database (it should be in the SSMS Database properties, under the Options page). To tunr Forced Parameterization off execute this command:



I ran into this situation today and the fix that solved my problem is to use WITH (NOLOCK) while doing a select on tables:

Eg: If your stored proc has T-SQL that looks like below:

SELECT * FROM [dbo].[Employee]  

Change it to

SELECT * FROM [dbo].[Employee] WITH (NOLOCK)  

Hope this helps.


I've had off-hours jobs fubar my indexes before and I've gotten the same result as you describe. sp_recompile can recompile a sproc... or, if that doesn't work, the sp_recompile can be run on the table and all sprocs that act on that table will be recompiled -- works for me every time.


I ran into this problem before as well. Sounds like your indexes are out of whack. To get the same behavior in SSMS, add this before the script


Does it timeout as well? If so, it's your indexing and statistics


It's most likely index-related. Had a similar issue with .Net app vs SSMS (specifically on a proc using a temp table w/ < 100 rows). We added a clustered index on the table and it flew from .Net thereafter.


Checked and this server, a development server, was not running SQL Server 2005 SP3. Tried to install that (with necessary reboot), but it didn't install. Oddly now both code and SSMS return in subsecond time.

Woot this is a HEISENBUG.


I've seen this behavior before and it can be a big problem with o/r mappers that use sp_executesql. If you examine the execution plans you'll likely find that the sp_executesql query is not making good use of indexes. I spent a fair amount of time trying to find a fix or explanation for this behavior but never got anywhere.


Most likely your .Net programs pass the variables as NVARCHAR, not as VARCHAR. Your indexes are on VARCHAR columns I assume (judging from your script), and a condition like ascii_column = @unicodeVariable is actually not SARG-able. The plan has to generate a scan in this case, where in SSMS would generate a seek because the variable is the right type.

Make sure you pass all your string as VARCHAR parameters, or modify your query to explicitly cast the variables, like this:

SELECT dv.ID  FROM dbo.DictionaryValue AS dv  WHERE dv.Word LIKE '%' + CAST(@FieldCheckValue5 AS VARCHAR(128)) + '%'  

Note:If u also have question or solution just comment us below or mail us on toontricks1994@gmail.com
Next Post »