Database Command Timeouts: Performance Differences between .NET and Management Studio

Overview¶

Why are there performance differences when a SQL statement is called from .NET app versus when the same call is made in Management Studio?

Resolution 1: Recompilation¶

The root of the problem is a stale execution plan for the stored procedure being called. The first time the stored procedure is called after it’s compiled, SQL Server builds an execution plan for it based on the parameter values submitted. The solution was to recompile the stored procedure, then execute it within Management Studio with the parameters that causes the timeout when called from .NET. This causes SQL Server to build a new execution plan based on parameter values that returned data.

Google "parameter sniffing SQL Server"
If it's just one stored procedure, recompile it, then immediately run it in Management Studio with the parameters of interest.
http://stackoverflow.com/questions/2785354/why-are-there-performance-differences-when-a-sql-function-is-called-from-net-ap/2785368#2785368
http://stackoverflow.com/questions/211355/parameter-sniffing-or-spoofing-in-sql-server

Resolution 2: Variable Substitution¶

Old Code¶

create procedure dbo.MyProcedure (
    @regionID int
    ) as 

. . .
where RegionID = @regionID

New Code¶

create procedure dbo.MyProcedure (
    @regionID int
    ) as 

declare @l_RegionID int

set @l_RegionID = @regionID

. . .
where RegionID = @l_RegionID