Asp.Net在运行存储过程时出现超时错误

时间:2021-12-12 06:40:37

I am using asp.net, .NET 3.5, C#, and SQL Server Express 2005.

我使用的是asp.net,.NET 3.5,C#和SQL Server Express 2005。

I have created a stored procedure in SQL, and when I run SP from SQL server it takes less than 1 second to return results. I have also tried that query in query analyzer and it also gives me results in less than 1 second. But when I try to call this SP from .NET (C#), it takes a long time, and then gives a timeout error.

我在SQL中创建了一个存储过程,当我从SQL服务器运行SP时,返回结果所需的时间不到1秒。我也在查询分析器中尝试过该查询,它也在不到1秒的时间内给出了结果。但是当我尝试从.NET(C#)调用此SP时,需要很长时间,然后给出超时错误。

Here is the code I am using to call the stored procedure:

这是我用来调用存储过程的代码:

SqlConnection con = new SqlConnection();

con.ConnectionString = System.Configuration.ConfigurationManager.ConnectionStrings["ConnectionString"].ConnectionString;
con.Open();

SqlCommand command = new SqlCommand("spReport_SiteUsage_KP", con);

command.CommandType = CommandType.StoredProcedure;

command.Parameters.Add(new SqlParameter("@fromDate", SqlDbType.DateTime));

command.Parameters.Add(new SqlParameter("@toDate", SqlDbType.DateTime));

command.Parameters[0].Value = Convert.ToDateTime(DatePicker1.SelectedDate.ToShortDateString());

command.Parameters[1].Value = DatePicker2.SelectedDate;

int i = command.ExecuteNonQuery();

con.Close();

Store Procedure :

商店程序:

set ANSI_NULLS ON
set QUOTED_IDENTIFIER ON
GO
ALTER PROCEDURE [dbo].[spReport_SiteUsage_KP]
    @fromDate datetime = null,
    @toDate datetime = null
AS
    truncate table dbo.RPT_SiteUsage

IF (@FromDate is not null and @ToDate is not null) --Hourly Report, grouped by hour
Begin   

    insert into RPT_SiteUsage 
    select '' as ReportType, 
    'Site Usage for '+ datename(mm,@fromDate)+' '+datename(dd,@fromDate)+', '+datename(yy,@fromDate) + 
    ' To '+datename(mm,@toDate)+' '+datename(dd,@toDate)+', '+datename(yy,@toDate) as ReportTitle,
    min(@fromDate) as FromDate,max(@toDate) as ToDate,
    isnull(count(s.SessionId),0) VisitsTotal,
    isnull(count(distinct(s.cookieid)),0) VisitsUnique,
    isnull(sum(PagesVisited),0) PageViews, 
    isnull(round(avg(convert(decimal(10,2),PagesVisited)),2),0) PagePerVisit,  
    isnull(min(PagesVisited),0) MinNoPageViews, 
    isnull(max(PagesVisited),0) MaxNoPageViews,
    isnull(round(avg(convert(decimal(10,2),TimeInSiteMinutes)),2),0) AvgTimeInSite, 
    isnull(min(TimeInSiteMinutes),0) MinTimeSpent, 
    isnull(max(TimeInSiteMinutes),0) MaxTimeSpent, 
    isnull(sum(NewPeople),0) as NewVisitors
    from
    dbo.UMM_UserAction ua inner join dbo.UMM_Session s on ua.SessionId=s.Sessionid
    left join
        (select ua.sessionId, datediff(ss,min(Actiondate),max(Actiondate))/60 TimeInSiteMinutes
         from dbo.UMM_UserAction ua
         where ActionDate between @fromDate and @toDate
         group by ua.sessionid
         ) sessionTime on ua.sessionId = sessionTime.sessionid
    left join
        (select ua.sessionId, 0 as NewPeople
        from dbo.UMM_UserAction ua 
            inner join dbo.UMM_Session s on ua.SessionId=s.SessionId
            inner join dbo.UMM_Cookie c on s.CookieId=c.CookieId
            where ua.actiondate< @fromDate --this is the from date
        group by UserId,ua.sessionId    
         ) Old on ua.sessionId = Old.sessionid
    left join
        (select ua.sessionId,count(distinct(uaP.PageEntryId)) as PagesVisited
        from dbo.UMM_UserAction ua,
        dbo.UMM_UserActionPageReview uaP 
        where ua.UserActionId=uaP.UserActionId
        and ActionDate between @fromDate and @toDate
        group by ua.sessionId
        )pVisited on ua.sessionId = pVisited.sessionId
    where ActionDate between @fromDate and @toDate

    IF (select count(*) from RPT_SiteUsage)=0
        insert into RPT_SiteUsage 
        select '(1 day)' as ReportType, 
        'Site Usage for '+datename(mm,@fromDate)+' '+datename(dd,@fromDate)+', '+datename(yy,@fromDate) + 
        ' To '+datename(mm,@toDate)+' '+datename(dd,@toDate)+', '+datename(yy,@toDate) as ReportTitle,
        min(@fromDate) as FromDate,max(@toDate) as ToDate,
        0 as VisitsTotal,
        0 as VisitsUnique,
        0 as PageViews, 
        0 as PagePerVisit,  
        0 as MinNoPageViews, 
        0 as MaxNoPageViews,
        0 as AvgTimeInSite, 
        0 as MinTimeSpent, 
        0 as MaxTimeSpent, 
        0 as NewVisitors

END

4 个解决方案

#1


Another idea, the TimeOut of each SqlCommand is also controlled individually, so, you can control it with CommandTimeOut property.

另一个想法是,每个SqlCommand的TimeOut也是单独控制的,因此,您可以使用CommandTimeOut属性来控制它。

command.CommandTimeout = 120;

However, I would check the execution plan to see where is it wasting or hogging db resources, I suggest this just for experiment, not on production.

但是,我会检查执行计划,看看它在哪里浪费或占用数据库资源,我建议这只是为了实验而不是生产。

#2


Well - I would say there's an error in your connection string. Please check it.

好吧 - 我会说你的连接字符串有错误。请检查一下。

#3


If it takes long before the query returns an error, there is probably something wrong with your connection (string).

如果在查询返回错误之前需要很长时间,那么您的连接可能有问题(字符串)。

#4


It could be the fun issue with a bad query plan cached on the proc. Especially if the guts of the proc just as a Query in Query Analyzer runs fine. Check this link out on how to resolve the situation: http://www.mssqltips.com/tip.asp?tip=1304

在proc上缓存错误的查询计划可能是一个有趣的问题。特别是如果proc的内核就像查询分析器中的查询一样运行正常。请查看此链接以了解如何解决此问题:http://www.mssqltips.com/tip.asp?tt = 1304

#1


Another idea, the TimeOut of each SqlCommand is also controlled individually, so, you can control it with CommandTimeOut property.

另一个想法是,每个SqlCommand的TimeOut也是单独控制的,因此,您可以使用CommandTimeOut属性来控制它。

command.CommandTimeout = 120;

However, I would check the execution plan to see where is it wasting or hogging db resources, I suggest this just for experiment, not on production.

但是,我会检查执行计划,看看它在哪里浪费或占用数据库资源,我建议这只是为了实验而不是生产。

#2


Well - I would say there's an error in your connection string. Please check it.

好吧 - 我会说你的连接字符串有错误。请检查一下。

#3


If it takes long before the query returns an error, there is probably something wrong with your connection (string).

如果在查询返回错误之前需要很长时间,那么您的连接可能有问题(字符串)。

#4


It could be the fun issue with a bad query plan cached on the proc. Especially if the guts of the proc just as a Query in Query Analyzer runs fine. Check this link out on how to resolve the situation: http://www.mssqltips.com/tip.asp?tip=1304

在proc上缓存错误的查询计划可能是一个有趣的问题。特别是如果proc的内核就像查询分析器中的查询一样运行正常。请查看此链接以了解如何解决此问题:http://www.mssqltips.com/tip.asp?tt = 1304