Hi Simon, I can't explain the difference between SQL Execution Time and ADO.Net timeouts. Here is a thought: I came across a situation recently where a .Net application was reporting a Time Out Exception and when I looked at the inner exception it stated that the application could not obtain a connection from the connection pool within the required period (don't know what period this would be). Essentially the Connection Pool has been exhausted. Are you collecting the Inner Exception information? Regards, Michael O'Dea-Jones From: [email protected] [mailto:[email protected]] On Behalf Of Simon Haigh Sent: Wednesday, 28 July 2010 12:11 PM To: ozDotNet Subject: RE: SQL/ADO.NET Timeout Error
Michael, We're assuming that both the connection and the querys are OK because the process itself successfully runs between 5000-7000 times a day. Its only recently that we've been getting the timeouts on the query and the discovered the unexplained differences between the elapsed realtime and the elapsed duration as reported by the SQL server. Correcting the timeouts themselves will probably involved adding another index (according to our DBA). But I was interested in why there was a difference between the time the query takes in realtime before a timeout and the same duration as reported by the SQL Server trace log. Simon ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Michael O'Dea-Jones Sent: Wednesday, 28 July 2010 12:03 PM To: ozDotNet Subject: RE: SQL/ADO.NET Timeout Error Hi Simon, The SqlConnection has a Connection Timeout (Default 15 sec). The SqlCommand has a Command Timeout (Default 30 sec). What's important is that the client application could not establish a connection and execute the command within the default timeout periods. Check your Connection strings and Permissions. Regards, Michael O'Dea-Jones From: [email protected] [mailto:[email protected]] On Behalf Of Simon Haigh Sent: Wednesday, 28 July 2010 11:54 AM To: ozDotNet Subject: SQL/ADO.NET Timeout Error Hi all. Not strictly a DotNet question but I'm sure somebody will know the answer. I have an SQL query that occassionally returns with a timeout error. We know that the default timeout for ADO.Net is 30sec and there are no default timeouts set on the SQL2K5 server. So we ran a trace and discovered that the query was running for approximately 0.7 seconds realtime but returning a 30 second duration in the trace log. Not particularly worried about the fact thatt the query is timing out but why the difference between realtime and the duration time reported by the SQL server. So can anybody explain why the difference between realtime and SQL query duration time? Thanks Simon ************************************************************************************************************************ This email (including all attachments) is confidential, may contain personal or legally privileged information and is intended solely for the named addressee. Confidentiality or privilege is not waived or lost because this email has been sent to you by mistake. If you have received it in error, please let us know by reply email, delete it from your system and destroy any copies. This email is also subject to copyright. No part of it should be reproduced, adapted or communicated without the written consent of the copyright owner. Any personal information in this email must be handled in accordance with the Privacy Act 1988 (Cth). Emails may be interfered with, may contain computer viruses or other defects and may not be successfully replicated on other systems. Pillar Administration makes no representations and gives no warranties in relation to these matters and does not accept liability for any loss or damage which may result from this email. If you have any doubts about the authenticity of an email purportedly sent by Pillar Administration, please contact us immediately. ************************************************************************************************************************ ************************************************************************************************************************ This email (including all attachments) is confidential, may contain personal or legally privileged information and is intended solely for the named addressee. Confidentiality or privilege is not waived or lost because this email has been sent to you by mistake. If you have received it in error, please let us know by reply email, delete it from your system and destroy any copies. This email is also subject to copyright. No part of it should be reproduced, adapted or communicated without the written consent of the copyright owner. Any personal information in this email must be handled in accordance with the Privacy Act 1988 (Cth). Emails may be interfered with, may contain computer viruses or other defects and may not be successfully replicated on other systems. Pillar Administration makes no representations and gives no warranties in relation to these matters and does not accept liability for any loss or damage which may result from this email. If you have any doubts about the authenticity of an email purportedly sent by Pillar Administration, please contact us immediately. ************************************************************************************************************************
