Resolución de un problema de time de espera de ADO en VB6

Me encuentro con un problema al completar un set de loggings 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 set de resultados es pequeño, pero cuando llega a ser unos cientos de loggings, lleva mucho time. Más de 800 loggings 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 exception aumentando el time de espera del command, 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 time. Algo así como comprimir los resultados para que no tome tanto time. El set de loggings se abre de la siguiente manera:

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 toma más time por un factor de 100 que ambas métricas para las consultas en SSMS. El text 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 networking o el proveedor tener algún impacto sobre esto?

Estadísticas de Profiler:

  • Desde la aplicación cliente: 7041720 lecturas, 59458 ms de duración, 3900 recuentos de filas
  • Desde SSMS: 30802 lecturas, 238 ms de duración, 3900 recuentos de filas

Parece que está utilizando un plan de ejecución diferente, pero la consulta es exactamente la misma y no estoy seguro de cómo comprobar el plan de ejecución que el cliente podría estar utilizando si es diferente de lo que se muestra en SSMS.

800+ records requires about 5 minutes = problema de consulta.

mira tu plan de ejecución:

En SSMS, ejecuta:

SET SHOWPLAN_ALL ON

luego ejecute su consulta, no producirá el set de resultados esperado, sino un plan de superación sobre cómo la database está recuperando sus datos. La mayoría de las consultas erróneas suelen escanear tablas (ver todas las filas de la tabla, que es lenta), así que busque la palabra "ESCANEAR" en la columna StmtText . Trate de descubrir por qué el índice no se está utilizando en esa tabla (el nombre estará ahí con la palabra "ESCANEAR"). Si se une a múltiples tablas y tiene múltiples SCAN, concéntrese primero en las tablas más grandes.

Sin más información, esta es la mejor ayuda "genérica" ​​que puede get.

EDITAR
Al leer su pregunta, no estoy seguro de si quiere decir que siempre es rápido desde SSMS, sin importar las filas, sino que es más lento desde VB a medida que aumentan las filas. Si ese es el caso, verifique esto: http://www.google.com/search?q=sql+server+fast+from+ssms+slow+from+application&hl=en&num=100&lr=&ft=i&cr=&safe=images

podría ser algo así como: parámetro sniffing o parameters de connection inconsistentes (ANSI nulls, arithabort, etc.)

para las configuraciones de connection, intente ejecutarlas desde SSMS y desde VB6 (agréguelos al set de resultados) y vea si hay alguna diferencia:

 SELECT SESSIONPROPERTY ('ANSI_NULLS') --Specifies whether the SQL-92 compliant behavior of equals (=) and not equal to (<>) against null values is applied. --1 = ON --0 = OFF SELECT SESSIONPROPERTY ('ANSI_PADDING') --Controls the way the column stores values shorter than the defined size of the column, and the way the column stores values that have trailing blanks in character and binary data. --1 = ON --0 = OFF SELECT SESSIONPROPERTY ('ANSI_WARNINGS') --Specifies whether the SQL-92 standard behavior of raising error messages or warnings for certain conditions, including divide-by-zero and arithmetic overflow, is applied. --1 = ON --0 = OFF SELECT SESSIONPROPERTY ('ARITHABORT') -- Determines whether a query is ended when an overflow or a divide-by-zero error occurs during query execution. --1 = ON --0 = OFF SELECT SESSIONPROPERTY ('CONCAT_NULL_YIELDS_NULL') --Controls whether concatenation results are treated as null or empty string values. --1 = ON --0 = OFF SELECT SESSIONPROPERTY ('NUMERIC_ROUNDABORT') --Specifies whether error messages and warnings are generated when rounding in an expression causes a loss of precision. --1 = ON --0 = OFF SELECT SESSIONPROPERTY ('QUOTED_IDENTIFIER') --Specifies whether SQL-92 rules about how to use quotation marks to delimit identifiers and literal strings are to be followed. --1 = ON --0 = OFF 

haga su consulta como (para que pueda ver la configuration de connection en VB6):

 SELECT col1, col2 ,SESSIONPROPERTY ('ARITHABORT') AS ARITHABORT ,SESSIONPROPERTY ('ANSI_WARNINGS') AS ANSI_WARNINGS FROM ...