Different plans or buffers for different connections? We had an issue in our dev environment where a procedure call timed out from the web server after 30 seconds. I traced the query and ran it manually (same params and all) from SSMS and it executed in about 2 seconds. I then ran

dbcc dropcleanbuffers
dbcc freeproccache


and after that the call from the web server also completed in time just fine.

I would suspect that the same plan should be used since I was using the exact same parameters from both connections, but I'm not sure.

My question is: Can there be different plans or buffers for different connections? Or could it have been some other side effect caused by me running the above dbcc-commands?
When you say "same params and all" then you may find different credentials were used or the same compiled plan wasn't re-used based on timing. 

I suspect here that the first web call and the SSMS call used different plans. The DBCCs then cleared the plan, so the second web call worked as expected

There are criteria that determine plan re-use such as using schema on all object references (eg dbo.table not table) which will be affected by different credentials.

However, the main culprit is usually parameter sniffing. See


Does restarting SQL Server speed it up?
Suddenly Slow Execution Plan for Stored Proc
Code creates different plan when ran ad-hoc vs. in a stored procedure


Failing that, some SET options may be different too:


Why would SET ARITHABORT ON dramatically speed up a query?


Note: these follow through to good background reading...