tags:

views:

1466

answers:

3

This is not a connection timeout as a connection to the database is made fine. The problem is that the stored procedure that I'm calling takes longer than, say, 30 seconds and causes a timeout.

The code of the function looks something like this:

SqlDatabase db = new SqlDatabase(connectionManager.SqlConnection.ConnectionString);
return db.ExecuteScalar(Enum.GetName(typeof(StoredProcs), storedProc), parameterValues);

The ExecuteScalar call is timing out. How can I extend the timeout period of this function?

For quick stored procedures, it works fine. But, one of the functions takes a while and the call fails. I can't seem to find any way to extend the timeout period when the ExecuteScalar function is called this way.

+8  A: 

you do this by setting the SqlCommand.CommandTimeout property

Mladen Prajdic
Which would work great if I was using a SqlCommand... but, I'm not.
BoltBait
Yes, you are. SqlDatabase isn't part of the standard data provider; it's a wrapper class that someone has written, and it will use an SqlCommand object internally.
Joel Coehoorn
The "someone" may be Microsoft, though -- is this the SQLDatabase class from Microsoft.Practices.EnterpriseLibrary?
Richard Dunlap
@Joel, that function is defined in a file called Microsoft.Practices.EnterpriseLibrary.Data.dll Hmmm... not sure if I have the source code for that. Searching...
BoltBait
Rewrite it to use db.CreateConnection(); the you'll have 4-5 extra lines of code, but easy access to the SqlCommand object.
nos
A: 

Mladen is right but if you have to do this you probably have a bigger problem with the proc itself. Under load it might take much longer than your new timeout. Might be worth spending some quality time with the proc to optimize.

n8wrl
Thanks for telling me to go optimize my application. Sigh. In the long run that may happen, but for TODAY I just need to get this thing running.
BoltBait
I certainly meant no offense. It's just that if SQL is timing out, it is unlikely you'll be able to find a timeout # that will work in every situation. You WANT SQL to time out in many cases and the default is still pretty long.
n8wrl
+4  A: 

If you are using the EnterpriseLibrary (and it looks like you are) try this:

 Microsoft.Practices.EnterpriseLibrary.Data.Database db = Microsoft.Practices.EnterpriseLibrary.Data.DatabaseFactory.CreateDatabase("ConnectionString");
 System.Data.Common.DbCommand cmd = db.GetStoredProcCommand("StoredProcedureName");
 cmd.CommandTimeout = 600;
 db.AddInParameter(cmd, "ParameterName", DbType.String, "Value");

 // Added to handle paramValues array conversion
 foreach (System.Data.SqlClient.SqlParameter param in parameterValues) 
 {
     db.AddInParameter(cmd, param.ParameterName, param.SqlDbType, param.Value);
 }

 return cmd.ExecuteScalar();

Edited to handle the paramValues array directly based on the comments. I also included your ConnectionString value:

Microsoft.Practices.EnterpriseLibrary.Data.Database db = Microsoft.Practices.EnterpriseLibrary.Data.DatabaseFactory.CreateDatabase(connectionManager.SqlConnection.ConnectionString);
System.Data.Common.DbCommand cmd = db.GetStoredProcCommand("StoredProcedureName", parameterValues);
cmd.CommandTimeout = 600;
return cmd.ExecuteScalar();
Chris Porter
Trying this now...
BoltBait
Hmmm... I don't have access to the ParameterNames. The parameterValues variable in my sample code is defined as "object[] parameterValues". Can I still add the parameters without knowing the names only the order?
BoltBait
I added code that should convert your paramValues array into the parameters expected by the DbCommand.
Chris Porter
No need. You just add it to the GetStoredProcCommand command.
BoltBait
Nice find, edited to show "proper" solution. Did this solve your issue?
Chris Porter
I'm not sure yet. I just made the changes to test, but it isn't working. I'm still tinkering and will report back when solved.
BoltBait
That fixed it. Thanks. My code now looks like the second code block in your post.
BoltBait