Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 SQL Server 2000 Forums
 SQL Server Development (2000)
 QUERY TIMES OUT FROM ADO BUT RUNS FINE IN QUERY AN

Author  Topic 

MartinSmith
Starting Member

17 Posts

Posted - 2004-09-07 : 10:18:20
Hi,

A few times recently I have encountered issues whereby a query called from ADO within VB times out after 30 seconds, Yet the same query called from Query Analyzer executes in less than a second.

There is a consistent pattern in that when one query starts doing this it will continue to do so until the server is rebooted. Running Profiler will show the expected text (e.g. "exec dbo.ReviewGetDetails 56, 0") and pasting this text into Query Analyzer works fine, it's just the call from the VB App that falls over.

The result set for this query is very small so I can't believe it's anything to do with the amount of data being returned.

The only difference I can see between the 2 calls in QA are that one is a SQL:Batch... event and the other is a RPC:Batch... event

Any ideas?

Cheers

Martin

spirit1
Cybernetic Yak Master

11752 Posts

Posted - 2004-09-07 : 10:32:35
set the SqlCommand.ConnectionTimeout = 5*60 (5 minutes) or more
QA doesn't have a timeout it just keeps running.

use the profiler to see what is taking so long...

Go with the flow & have fun! Else fight the flow
Go to Top of Page

MartinSmith
Starting Member

17 Posts

Posted - 2004-09-07 : 10:42:27
Hiya,

The point is though that 30 seconds should be quite sufficient as the exact same query only takes 1 second to run in QA!

Cheers,

Martin
Go to Top of Page

spirit1
Cybernetic Yak Master

11752 Posts

Posted - 2004-09-07 : 10:54:04
yes. so increase the ConnTimeout and use profiler to see what's going on if u run it from ado and from QA.

Go with the flow & have fun! Else fight the flow
Go to Top of Page

MartinSmith
Starting Member

17 Posts

Posted - 2004-09-22 : 06:47:11
I'm still getting this issue - anyone else have any ideas?
Go to Top of Page

slacker
Posting Yak Master

115 Posts

Posted - 2004-09-22 : 07:04:03
Have you tested other queries within your vb app and does it do the same thing? Maybe there is another odbc ( oledb? )driver you can try.
Go to Top of Page

Kristen
Test

22859 Posts

Posted - 2004-09-22 : 13:03:04
I would suggest you either use Profiled to see what is going on or, if you are not familiar with that, put some

INSERT INTO MyLogTable GetDate(), 'Now at Point A'

type statements in your SProc. You might find it has actually finished executing and its VB that has stalled!

Kristen
Go to Top of Page

MartinSmith
Starting Member

17 Posts

Posted - 2004-09-23 : 06:13:58
Hi,

A bit more info...

Increasing the timeout has no effect (eg. increasing it from 30 secs to 60 secs just means that instead of timing out after approx 30000 miliseconds it times out after 60000 miliseconds)

In profiler the only information I see is the

RPC:Batch starting info and the RPC:Batch completed info. Are there any other events I should be tracing to see what happens between these points?

The only difference I see in profiler between running the stored procedure in QA and running it from the VB app is the EventClass (RPC vs. SQL)

The stored procedure couldn't be simpler and just selects from a view.

CREATE PROCEDURE dbo.ReviewGetDetails
@CompanyID int = 0,
@ReviewID int = 0


AS
IF @ReviewID = 0
SELECT *
FROM ReviewLatestDetails_vw
WHERE CompanyID = @CompanyID
ELSE
SELECT *
FROM ReviewDetails_vw
WHERE ReviewID = @ReviewID


(NB It isn't always this stored proc that fails but that is the example I gave above...)

This is currently happening about once a week and whilst rebooting does (temporarily) fix it. It obviously isn't ideal!

I'm wondering whether it could be something like a dodgy pooled connection or something like that - is that possible?

Go to Top of Page

MartinSmith
Starting Member

17 Posts

Posted - 2006-08-22 : 15:34:54
OK.

Two years on from my original post but I am still curious about this issue.

I just had a similar issue again today.

This time a SQL 2005 stored procedure (that has always been working fine previously) suddenly decided to consistently timeout on my ASP.NET 2.0 site.

Again the query ran fine in Management Studio however.

This time I resolved it by adding the line "set arithabort on" to the beginning of the sp as that was the only difference in "SET" options that I could see between the ADO.NET Connection and the Mgmt Studio one.

I'm unsure whether this or the resultant recompile made the difference but all started working well again.

This does seem to be an occasional SQL problem. I'm sure I'm not the only person this ever happens to. Am I?

Anyone got a good explanation?
Go to Top of Page

shlms78
Starting Member

1 Post

Posted - 2006-08-22 : 17:51:50
Just Curious,

Is the SP you are currently having problems with similar in design to the original (Call the stored proc and execute one select or else execute another select)? In other words, the SP can return different result sets based on a parameter switch...

Yak In the Box
Go to Top of Page

MartinSmith
Starting Member

17 Posts

Posted - 2006-08-23 : 05:47:04
quote:
Originally posted by shlms78

Just Curious,

Is the SP you are currently having problems with similar in design to the original (Call the stored proc and execute one select or else execute another select)? In other words, the SP can return different result sets based on a parameter switch...

Yak In the Box



No. I don't mind posting the whole proc here in case anyone sees any constructs that are likely to be problematic (or may require ARITHABORT to be on). I'm not using indexed views or computed columns.







CREATE PROCEDURE [dbo].[spSelectChangeResults]
@DatasetId int,
@IndicatorId int,
@AdditionalGeographicEntities varchar(200),
@UserId int,
@SiteId int,
@ApplicationId int = 5,
@IndicatorChangeTitle varchar(500) OUTPUT,
@NumberOfYears int OUTPUT,
@NumberOfGeographicEntities int OUTPUT

AS



--Determine: What Geographic Entities can the user see?

DECLARE @GeographicEntitiesToUse TABLE
(
[GeographicEntityId] [int] NOT NULL
)



INSERT INTO @GeographicEntitiesToUse
SELECT tblGeographicEntitiesToUse.[value]
FROM fnSplit(@AdditionalGeographicEntities, ',') tblGeographicEntitiesToUse INNER JOIN
tblGroupApplicationGeographicEntities ON tblGeographicEntitiesToUse.[value] = tblGroupApplicationGeographicEntities.GeographicEntityId INNER JOIN
tblGroups ON tblGroupApplicationGeographicEntities.GroupId = tblGroups.GroupId INNER JOIN
tblUserGroups ON tblGroups.GroupId = tblUserGroups.GroupID
WHERE (tblUserGroups.UserID = @UserID) AND (tblGroups.SiteId = @SiteId) AND
(tblGroupApplicationGeographicEntities.ApplicationId = @ApplicationId)


--Out of this list of GEs. Determine:
--For Each Year in the resultset what is the most recent datarelease for geographic entities at this Spatial Level
--that is viewable to this site?
DECLARE @tblMostRecentDataReleases TABLE(
[SpatialLevelId] [int] NOT NULL ,
[IndicatorId] [int] NOT NULL ,
[Year] [int] NOT NULL ,
[DataReleaseId] [int] NULL
)

INSERT INTO @tblMostRecentDataReleases
SELECT tblGeographicEntities.SpatialLevelId, tblMatrix.IndicatorId, tblMatrix.[Year], MAX(tblMatrix.DataReleaseId) AS DataReleaseId
FROM tblSiteDataReleases INNER JOIN
tblMatrix ON tblSiteDataReleases.DataReleaseId = tblMatrix.DataReleaseId INNER JOIN
tblGeographicEntities tblGeographicEntities_1 ON tblMatrix.GeographicEntityId = tblGeographicEntities_1.GeographicEntityId INNER JOIN
tblGeographicEntities INNER JOIN
@GeographicEntitiesToUse [@GeographicEntitiesToUse] ON tblGeographicEntities.GeographicEntityId = [@GeographicEntitiesToUse].GeographicEntityId ON
tblGeographicEntities_1.SpatialLevelId = tblGeographicEntities.SpatialLevelId
WHERE (tblSiteDataReleases.SiteId = @SiteId) AND (tblMatrix.IndicatorId = @IndicatorId)
GROUP BY tblGeographicEntities.SpatialLevelId, tblMatrix.IndicatorId, tblMatrix.[Year]




DECLARE @tmpResults TABLE (
[GeographicEntityId] [int] NOT NULL ,
[GeographicEntityName] [varchar] (100) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
[Year] [int] NOT NULL ,
[IndicatorValue] [float] NULL
)

INSERT INTO @tmpResults
SELECT tblMatrix.GeographicEntityId, tblGeographicEntities.GeographicEntityName, tblMatrix.[Year], tblMatrix.IndicatorValue
FROM @tblMostRecentDataReleases [@tblMostRecentDataReleases] INNER JOIN
tblMatrix ON [@tblMostRecentDataReleases].IndicatorId = tblMatrix.IndicatorId AND
[@tblMostRecentDataReleases].DataReleaseId = tblMatrix.DataReleaseId AND [@tblMostRecentDataReleases].[Year] = tblMatrix.[Year] INNER JOIN
tblGeographicEntities ON tblMatrix.GeographicEntityId = tblGeographicEntities.GeographicEntityId
INNER JOIN @GeographicEntitiesToUse [@GeographicEntitiesToUse] ON
tblGeographicEntities.GeographicEntityId = [@GeographicEntitiesToUse].GeographicEntityId




--In the event that we have 2 Geographic Entities with the same name but different IDs use a concatenation of the 2 so that
--the CrossTab data provider can tell them apart.
SELECT COALESCE (tblNonDuplicated.GeographicEntityName, [@tmpResults].GeographicEntityName + ' - ' + CONVERT(VARCHAR(6),
[@tmpResults].GeographicEntityId)) AS GeographicEntityName, [@tmpResults].[Year], [@tmpResults].IndicatorValue
FROM (SELECT GeographicEntityName
FROM @tmpResults [@tmpResults]
GROUP BY GeographicEntityName
HAVING (COUNT(DISTINCT GeographicEntityId) = 1)) tblNonDuplicated RIGHT OUTER JOIN
@tmpResults [@tmpResults] ON tblNonDuplicated.GeographicEntityName = [@tmpResults].GeographicEntityName
ORDER BY [@tmpResults].[Year], tblNonDuplicated.GeographicEntityName

--Sort out all Output Params

SELECT @IndicatorChangeTitle = IndicatorChangeTitle
FROM tblIndicators
WHERE (IndicatorId = @IndicatorId)

SELECT @NumberOfYears = COUNT(DISTINCT [Year]), @NumberOfGeographicEntities = COUNT(DISTINCT GeographicEntityId)
FROM @tmpResults




Go to Top of Page

pootle_flump

1064 Posts

Posted - 2006-08-23 : 08:20:00
I've had this problem (sproc suddenly becomes a problem for the client. Put the exact same command in QA and runs perfectly). I sorted it out pretty easily and so can only offer an unverified theory (you don't tend to investigate further once fixed). The cached plan for the sproc used by the client is no longer optimal (as they tend to become). For some reason the server generates a new plan for the sproc call from QA even if the call is, to all intents and purposes, identical. I just got the plan to be recreated next run and it this has sorted the problem the half dozen times or so it has happened to me.

EXEC sp_recompile spSelectChangeResults

Hope this helps out
Go to Top of Page

pootle_flump

1064 Posts

Posted - 2006-08-23 : 08:32:34
quote:
Originally posted by MartinSmith

I'm unsure whether this or the resultant recompile made the difference but all started working well again.

Oops missed this bit.

I think it is that simple. I forgot to mention that the first few times I got this it was using Access paa throughs. You have to pass a SQL string so a copy and paste to QA guarentees the string is identical. I first tried adding WITH RECOMPILE on the end and this caused the query to run at normal speed. That's what led me to changing the cached plan.
Go to Top of Page

spirit1
Cybernetic Yak Master

11752 Posts

Posted - 2006-08-23 : 08:33:27
you're probably experiencing what is known as parameter sniffing.
http://blogs.msdn.com/khen1234/archive/2005/06/02/424228.aspx


Go with the flow & have fun! Else fight the flow
blog thingie: http://weblogs.sqlteam.com/mladenp
Go to Top of Page

pootle_flump

1064 Posts

Posted - 2006-08-23 : 08:40:09
quote:
Originally posted by spirit1

you're probably experiencing what is known as parameter sniffing.
http://blogs.msdn.com/khen1234/archive/2005/06/02/424228.aspx

The crux of this problem (as I've always seen it) is not why a query runs poorly or smoothly, but why it runs well from one app submitting a string and poorly from another app submitting the same string.

Parameter sniffing is when the server creates a plan that is optimal for the set of parameters provided at compile time but not optimal for a subsequent call using different parameters. This (I would expect) would be application independent.

Does that make sense?
Go to Top of Page

MartinSmith
Starting Member

17 Posts

Posted - 2006-08-25 : 15:59:22
Thanks for the responses and the Parameter sniffing link.

Useful to know.

In that case does it store different versions of the execution plan concurrently depending on options such as arithabort?
Go to Top of Page

dashman
Starting Member

1 Post

Posted - 2009-02-25 : 15:53:40
I had a similar issue. What I did was add with recompile to my stored procedure that was having the problem as I found that it was using one of the parameters in a like clause. I believe this was causing the executed plan to provide varying results passed on parameter information.

Forcing recompilation at the prodedure level seemed to resolve the issue.
Go to Top of Page

SwePeso
Patron Saint of Lost Yaks

30421 Posts

Posted - 2009-02-25 : 16:16:23
Also don't use table variables if you expect the data to fill more than one page.



E 12°55'05.63"
N 56°04'39.26"
Go to Top of Page
   

- Advertisement -