views:

180

answers:

3

I have a problem with this one stored procedure that works 99% of the time throughout our application, but will time out when called from a particular part of the application.

The table only has 3 columns and contains about 300 records. The stored proc will only bring back one record and looks like this

"Select * from Table Where Column = @parameter"

When the sp is executed in management studio it takes :00 seconds.

The stored procedure is used a lot in our application, but only seems to time out in one particular part of our program. I can't think of any reason why such a simple sp would time out. Any ideas?

This is a vb.net desktop application and using sql server 2005.

+4  A: 

You've got some code that's already holding a lock on the table so it can't be read.

tvanfosson
You were correct. I added "with (nolock)" to my stored proc and it ran just fine. If I remove the "with (nolock)" then I get the timeout error again. Thank you for your help.
jacook11
A: 

you need to get performance metrics. Use the sql profiler to confirm that the SP is slow at that time or something else. If it is the sql that's slow at that time - consider things like locks that may be forcing your query to wait. Lets us know and we might be able to give more specific information at that point.

If it not the SP but say the VB code, a decent profile like RedGate's Ants or JetBrains' DotTrace may help.

Preet Sangha
+1  A: 

try

SELECT * FROM Table WITH (NOLOCK) WHERE Column = @parameter
stimpy77
Use NOLOCK only if accuracy of the data doesn't matter.
Frank Kalis
This indeed solved my issue. I added "with (nolock)" and my stored proc ran correctly. I removed the "with (nolock)" and it timed out just like it did before. Thanks for your help.I am new to stackoverflow and noticed that I can only select 1 answer as the "correct" answer. Since tvanfosson answered first, I marked his as the "correct" answer.
jacook11
Make sure you understand what NOLOCK really is doing, before you use it in your production code.
Frank Kalis
@Frank Kalis - The data that I am grabbing will hardly ever change. Maybe once a year at most. So there should be hardly any chance of a dirty read. Is that what you were concerned about?
jacook11
Yes. I've seen far too many people recommending NOLOCK as a quick performance win without mentioning the associated "risk". If that's acceptable for you, that's perfectly fine.It still might be worth investigating why things are slow. Running profiler can't hurt and may give better insights.
Frank Kalis