Me encuentro con un problema al completar un conjunto de registros ADO en VB6. La consulta (al llegar a SQLServer 2008) solo tarda aproximadamente 1 segundo en ejecutarse cuando la ejecuto usando SSMS. Funciona bien cuando el conjunto de resultados es pequeño, pero cuando llega a ser unos cientos de registros, lleva mucho tiempo. Más de 800 registros requieren aproximadamente 5 minutos para regresar (la consulta todavía demora 1 segundo en SSMS), y más de 6000 tarda más de 20 minutos. He "corregido" la excepción aumentando el tiempo de espera del comando, pero me preguntaba si había una forma de hacerlo funcionar más rápido, ya que no parece ser la consulta real que requiere tanto tiempo. Algo así como comprimir los resultados para que no tome tanto tiempo. El conjunto de registros se abre de la siguiente manera:Resolviendo un problema de tiempo de espera de ADO en VB6
myConnection.CommandTimeout = 2000
myConnection.ConnectionString = "Provider=SQLOLEDB;" & _
"Initial Catalog=DB_NAME;" & _
"Data Source=SERVER_NAME" & _
"Network Library=DBMSSOCN;" & _
"User ID=USER_NAME;" & _
"Password=PASSWORD;" & _
"Use Encryption for Data=True;"
myConnection.Open
myRecordSet.Open STORED_PROC_QUERY_STRING, myConnection, adOpenStatic, adLockReadOnly
Set myRecordSet.ActiveConnection = Nothing
myConnection.Close
Los datos devuelven 3 columnas utilizadas para llenar un cuadro combinado.
ACTUALIZACIÓN: Ejecuté el Analizador de SQL, y las instancias de la máquina cliente hacen más lecturas y toman más tiempo por un factor de 100 que ambas métricas para las consultas en SSMS. El texto de la consulta es el mismo tanto para SSMS como para la máquina cliente de acuerdo con el generador de perfiles, por lo que no creo que deba usarse un plan de ejecución diferente. ¿Podría la biblioteca de red o el proveedor tener algún impacto sobre esto?
estadísticas Profiler:
- A partir de la aplicación de cliente: 7041720 lee, duración 59458 ms, 3900 fila conteos
- De SSMS: 30802 lee, 238 ms duración, 3900 fila cuenta
Parece que está utilizando un plan de ejecución diferente, pero la consulta es exactamente la misma y no estoy seguro de cómo verificar el plan de ejecución que el cliente podría estar utilizando si es diferente. om lo que se muestra en SSMS.
¿Has probado eliminar el "Usar cifrado para datos"? – Andomar
No, pero esa no es realmente una opción disponible. Esta es una aplicación de cliente. –
Ha intentado perfilar las llamadas y [mirando los planes de ejecución] (http://stackoverflow.com/questions/3831644/why-does-a-database-query-only-go-slow-in-the-application/ 3831685 # 3831685) para verificar que esto definitivamente no es un problema de olfateo de parámetros –