ADO.Net DataReader timeout issue

Estoy usando ADO.Net + C# + VSTS 2008 + ADO.Net para conectar con SQL Server 2008 Enterprise. Estoy usando casi el mismo patrón/muestra mencionado aquí - usando ADO.Net DataReader para recuperar datos de una entrada (fila) por una entrada (fila).ADO.Net DataReader timeout issue

http://msdn.microsoft.com/en-us/library/haa3afyz.aspx

Mi pregunta es, si fijo el tiempo de espera SqlCommand en esta muestra, 1. Creo que el tiempo de espera se aplica a la cantidad de tiempo que podríamos utilizar como valor máximo para recuperar una fila specifc, no el total tiempo de espera para todo el bucle de entrada por entrada de datos?

Por cierto: me refiero bucle,

while (reader.Read()) 
{ 
    Console.WriteLine("{0}\t{1}", reader.GetInt32(0), 
     reader.GetString(1)); 
}

2. y este tiempo de espera sólo importa la cantidad de tiempo que se necesita para recuperar la entrada de datos de la base de datos, y este tiempo de espera no tiene nada que ver con la cantidad de tiempo que tratamos con cada entrada (por ejemplo, si establecemos el tiempo de espera en 20 segundos, y si tarda 1 segundo en recuperar una entrada de datos de la base de datos, y la lógica de la aplicación tarda 30 segundos en manipular la entrada de datos, el tiempo de espera nunca ocurrirá).

¿Lo entiende bien?

Fuente

2009-09-27 George2

El tiempo de espera del comando que puede establecer se aplica a cuánto tiempo le otorga a ADO.NET hacer su trabajo.

Si llama al cmdQuery.ExecuteNonQuery(), que no devuelve nada pero realiza una declaración de SQL, es el tiempo necesario para realizar esa declaración.

Si llama al cmdQuery.ExecuteReader() que devuelve un lector de datos, es el tiempo necesario para que ADO.NET construya/construya ese lector de datos para que pueda usarlo.

Si llama al cmdQuery.ExecuteScalar() que devuelve un único valor escalar, es el tiempo necesario para ejecutar la consulta y obtener ese único resultado.

Si utiliza dataAdapter.Fill() para completar una tabla de datos o un conjunto de datos, es el tiempo necesario para que ADO.NET recupere los datos y luego llene la tabla de datos o el conjunto de datos.

De manera general: el tiempo de espera se aplica a la parte del trabajo que ADO.NET puede hacer: ejecutar la instrucción, completar un conjunto de datos, devolver un valor escalar.

Por supuesto que sí NO se aplican al tiempo que se tarda USTED iterar a través de los resultados (en el caso de un lector de datos). Eso no tendría sentido en absoluto ...

Marc

Fuente

2009-09-27 18:36:42

Gracias Marc, 1. ¿Quiere decir para el escenario de DataReader, cuando recibo la instancia de DataReader, el tiempo de espera no tendrá ningún efecto? 2. En caso afirmativo, mi confusión es que leí algunos documentos antes de DataReader, ADO.Net recupera datos en un fasion de transmisión, es decir, no todos los datos se recuperan de SQL Server cuando se crea DataReader. Si esto es cierto, ¿debería haber más transferencia entre el cliente ADO.Net y el servidor SQL Server?Pero como dijiste, el tiempo de espera ya no tiene impacto después de que se crea DataReader, ¿por lo que no hay control de tiempo de espera para una transferencia de transmisión continua? – George2

Mi preocupación por mis comentarios anteriores es que los clientes retendrán DataReader durante mucho tiempo y creo que en modo de transmisión (dado que ADO.Net no puede predecir si el cliente desea leer más datos o simplemente romper el ciclo de lectura), el la conexión se mantendrá viva todo el tiempo. Quiero tener un control de tiempo de espera para tal comportamiento que obligue a dicho lector de larga duración a cerrar/liberar la conexión de ADO.Net. ¿Parece que el tiempo de espera de SqlCommand (utilizado para crear DataReader) no es lo que estoy buscando? Gracias. – George2

Tiene toda la razón: si mantiene el DataReader abierto durante un tiempo prolongado, la conexión subyacente se mantendrá abierta durante ese mismo tiempo. No hay límite de tiempo para evitar que haga esto. Es su responsabilidad asegurarse de no demorar demasiado. –

Sí, tienes razón. CommandTimeout significa el tiempo que necesita la base de datos para ejecutar el comando (cualquier comando)

Fuente

2009-09-27 17:39:39 Arthur

Lo que me confunde es, por DataReader SqlCommand, podríamos recuperar la entrada de datos uno por uno, pero para otros tipos SqlCommand, que recuperar datos de una sola vez. Entonces, para DataReader, el tiempo de espera se aplica solo para una entrada de datos, no para todo el ciclo de recuperación de entrada de datos. Apreciar si pudieras confirmar :-) – George2

Respuesta

Cuestiones relacionadas