Home/ Questions/Q 8833049
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-14T08:41:06+00:00

We have a program that connects to our DB and run some Stored Procedures

  • 0

We have a program that connects to our DB and run some Stored Procedures to get some data.

The database is a SQL Server 2008 and the program runs locally. The connection is via TCP/IP, but shared memory is enabled. And the timeout of the connection string is set to 45 sec.

When we run them through SQL Server Management Studio, it takes 0-5 seconds to run.
When we run it through code, it randomly times out.

To make some test, we increased the timeout from 45sec to few minutes. And also to discard any blocking issue we checked that the Stored Procedures only “selects” data (with no insert or update statement). And we have tried several table modifiers for the select statements like: nolock, readpast, …

Also I checked sp_who2 and dbcc opentran() and nothing is blocked… and the SPID of the .Net is running command .... For more details while the .Net is waiting a DB answer, through SQL Server Management Studio I can run the same statement (Stored Procedure or Select) without problems.

Any suggestion of what is happening?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The connection string timeout only influences the login timeout. You seems to hit a command timeout, and that can be changed only by modifying the CommandTimeout. The default value is 30 seconds, the recommended value is 0 (infinite timeout).

    As for why your procedure hits random slow execution, I recommend to start by reading Slow in the Application, Fast in SSMS? Understanding Performance Mysteries

    BTW, your query is likely not blocked. It executes a different plan that simply takes that long to execute. Checking for last_wait_type in sys.dm_exec_requests will likely reveal IO waits (PAGEIOLATCH, after to chasse any red-herring CXPACKET down the sys.dm_os_workers join…). But there is no point repeating the far more comprehensive and excellent article by Erland Sommarskog I originally linked.

    • 0