La diferencia es que usa planes diferentes. Se puede ver claramente en los READS. Asegurate de aplicar los SET de la conexion de manera identica.
Que proveedor estas usando? -- -------------------------------- Ing. José Mariano Alvarez SQL Total Consulting Bogota 3631 P3B 1407 Buenos Aires-Argentina Movil: (011)-15-4184-7541 Desde el exterior: (+54-911)-4184-7541 [email protected] 2009/2/19 [email protected] <[email protected]> > > > Mariano, abajo resumo los datos del sql profiler para ambas ejecuciones, > iguales parámetros y servidor. > > CPU Reads Duration > Mgm.Studio 469 27332 480 > Aplic. 413442 258713577 413738 > > Lucio, probé cambiarle la referencia al servidor en el web.config, pero > obtengo el mismo resultado; el servidor tiene seguridad mixta, la aplicación > se conecta con un usuario de Sql. > > De todos modos, en contra de tu hipótesis, pude ver que la aplic, para la > mayoría de otras consultas, funciona bien, incluso con esta misma consulta > modificada o simplificada funciona bien. > > Se trata de una consulta que tiene que armar una cuenta conrriente de > proveedor para lo cual hace unos 11 union (union all) de conjuntos; pude ver > que comentariando ciertos conjuntos, la consulta responde bien desd > ado.net también, con lo cual tendría la solución bastante focalizada. > > Lo que me confunde es porqué de la diferencia de comportamiento desde > ado.net y desde sql mgm, dado que la mayoría de las veces , uno asume que > la performance de una consulta son iguales o similares y ejecuta las pruebas > asumiendo eso. > > Lo único que se me ocurre pueda estar pasando, es algún issue relacionado > con bloqueos que ocurran desde ado.net dado el contexto con que se > ejecutan las consultas. > > Gracias >
