2009-07-10 69 views
31

Este no es un tiempo de espera de conexión, ya que la conexión a la base de datos está bien. El problema es que el procedimiento almacenado que llamo lleva más tiempo que, por ejemplo, 30 segundos y causa un tiempo de espera.Cómo extender el tiempo de espera de una consulta SQL

El código de la función se ve algo como esto:

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

La llamada ExecuteScalar es el tiempo de espera. ¿Cómo puedo extender el período de tiempo de espera de esta función?

Para procedimientos almacenados rápidos, funciona bien. Pero, una de las funciones demora un tiempo y la llamada falla. Parece que no puedo encontrar ninguna manera de extender el período de tiempo de espera cuando la función ExecuteScalar se llama de esta manera.

+4

OK, downvoting mi pregunta es simplemente grosero. Mi pregunta está claramente definida y (con suerte) tiene una respuesta. – BoltBait

Respuesta

27

Si está utilizando el EnterpriseLibrary (y parece que eres) intente esto:

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(); 

Editado para manejar la matriz paramValues ​​directamente sobre la base de los comentarios. También incluí el valor ConnectionString:

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(); 
+0

Probando esto ahora ... – BoltBait

+0

Hmmm ... No tengo acceso a ParameterNames. La variable parameterValues ​​en mi código de ejemplo se define como "object [] parameterValues". ¿Puedo agregar los parámetros sin conocer los nombres solo del pedido? – BoltBait

+0

Agregué un código que debería convertir su matriz paramValues ​​en los parámetros esperados por DbCommand. –

22

que hacerlo estableciendo la propiedad SqlCommand.CommandTimeout

+3

Lo que funcionaría genial si estuviera usando un SqlCommand ... pero no lo soy. – BoltBait

+3

Sí, lo eres. SqlDatabase no es parte del proveedor de datos estándar; es una clase contenedora que alguien ha escrito, y usará un objeto SqlCommand internamente. –

+3

Sin embargo, el "alguien" puede ser Microsoft: ¿es esta la clase SQLDatabase de Microsoft.Practices.EnterpriseLibrary? –

0

Mladen es correcta, pero si usted tiene que hacer esto es probable que tenga un problema más grande con el propio proc. Bajo carga puede tomar mucho más tiempo que su nuevo tiempo de espera. Podría valer la pena gastar un poco de tiempo de calidad con el proceso para optimizar.

+1

Gracias por pedirme que optimice mi aplicación. Suspiro. A la larga eso puede suceder, pero para HOY solo necesito poner esto en marcha. – BoltBait

+0

Ciertamente no quería ofender. Es solo que si SQL está agotando el tiempo, es poco probable que pueda encontrar un tiempo de espera # que funcione en todas las situaciones. En muchos casos, QUIERES que SQL exceda el tiempo de espera y el valor predeterminado sigue siendo bastante largo. – n8wrl

2

prueba este tiempo de espera

SqlConnectionStringBuilder connectionStringBuilder = new SqlConnectionStringBuilder(connection.ConnectionString); 
connectionStringBuilder.ConnectTimeout = 180; 
connection.ConnectionString = connectionStringBuilder.ConnectionString; 

connection.Open(); 
SqlCommand command = new SqlCommand("sp_ProcedureName", connection); 
command.CommandType = CommandType.StoredProcedure; 
command.CommandTimeout = connection.ConnectionTimeout; 
command.ExecuteNonQuery(); 
connection.Close(); 
5

creo que esto podría ser una mejor manera de hacer esto (a partir de Enterprise Library 6.0):

SqlDatabase db = new SqlDatabase(connectionManager.SqlConnection.ConnectionString); 
System.Data.Common.DbCommand cmd = db.GetStoredProcCommand(storedProc, parameterValues); 
cmd.CommandTimeout = 600; 
return db.ExecuteScalar(cmd); 
+0

gracias compañero esto ahorra muchas horas. muy apreciado –

Cuestiones relacionadas