Consulta lenta desde VFP y Rápido desde SQL

[Alci]

Hola a todos,

Tengo un reporte que realiza una simple consulta no muy compleja, desde el lado del SQL es decir desde SQL Server Management Studio la consulta en realiza en pocos segundos, pero al ejecutar desde la aplicación demora mucho mas.

El select es con cuatro tablas que realiza un suma de unos campos para mostrar el saldo total de la deuda de los cliente, no tiene nada de especial, tiene filtro por tipo de crédito, código de cliente y cosas por el estilo.

Desde el lado del SQL M.S. demora entre 1 a 3 segundo en mostrar el resultado, pero desde el informe demora aproximadamente entre 30 a 40 segundos, ya es mucho para estar mirando el monitor jejeje.

Porque podría ser eso, alguien tiene alguna sugerencias?

Saludos,

Alcides.

[Luis Maria Guayan]

¿Podrías poner la clausula SELECT e informar cuantos registros es el resultado?

Luis María Guayán
Tucumán, Argentina
_________________________
http://www.PortalFox.com
Nada corre como un zorro
_________________________

[Douglas Sánchez]

Hola, es interesante este tema, sorry x meter mi cuchara, pero he notado desde sql server 2005 que las consultas se hacen lentas desde vfp, en sql server 2000, bien rapido y en mysql server ya ni digamos consigos respuestas super rapidas, pero como les dije cualquier consulta de tipo

select idclientes, codcliente, nombres, saldo from tblclientes  order by idclientes

select idproveedores, codprov, nombres, saldo from tblProveedores  order by idproveedores

Hice estas dos consultas y dilata demasiado en vfp y vb.net, para lo que dilata en mysql server o mariadb.

Esta consulta la cargue en un form, dilata el triple de lo que me carga en sql server e incluso de oracle recibo mayor velocidad.

Creo que es lo mismo que te sucede, o sera coincidencia.

Saludes

Douglas

--
Ing. Douglas Sánchez Guillén

      Consultor Informatico

Claro: 505 88495476

[Luis Mata]

Yo trabaje con SQL 2008 actualmente con 2012, como te dicen seria bueno que coloques el codigo para mirarlo.

[Ariel D'Alfeo]

probaste configurando el ODBC para sqlserver? a mi me pasaba y con eso se soluciono

-- 
Ariel D'Alfeo
Córdoba, Argentina

[Fernando D. Bozzo]

En general todos los problemas de lentitud de las consultas del lado de FoxPro suelen ser porque no se usan los índices correctamente, o sea, la optimización Rushmore.

Eso se puede verificar poniendo SYS(3054,11) en la ventana de comandos antes de ejecutar la consulta, luego el resultado esperado debería decir que la optimización es parcial o total, pero si dice "none" (o ninguna), entonces este es el problema.

Si el filtro se está haciendo por tipo de crédito, código de cliente y otros, entonces debería haber un índice con cada una de esas claves, aunque en Fox la mayor velocidad se suele obtener con una única clave que sea la suma de los campos del filtro, aunque incluso con los índices muchos suelen poner mal luego la condición en el Select-SQL.

[ZeRoberto]

Fernando no son tablas nativas, el usa SQL Server, yo también note eso, tengo unas consultas que me usa vistas anidadas y en el mismo navicat lo hace rapidicimo pero en el Fox se demora unos varios segundo, hasta el momento no se el porque. Aunque creo que el problema es por que el vfp no maneja multi hilos para llenar la tabla, una vez que haces el select el vfp no para hasta llenar toda la tabla, mientras que en Lazarus le llena una parte y luego le va llenando de a pocos.

Saludos

--
btnMyVideo.Click()

[Alci]

Tratare de explicar lo que paso.

El sistema esta diseñado para ser multi-empresa, en todas las tablas tiene el código de la empresa...

La consulta devuelve correctamente los datos porque en la BD que utilizo hay una sola empresa, lo que paso fue que en la consulta no se realizo ningún filtro por empresa, no pase como parametro el código de la empresa.

Al agregar en el filtro el código de la empresa mejoro la velocidad de la consulta, prácticamente se normalizo.

Supongo que afecto al rendimiento al tener claves compuestas con el código de la empresa en las tablas y por no utilizarlo dentro de la clausula where, porque en los join's si interviene.

Re-configurando los driver o utilizando el SQL Native Client o SQL Server no cambiaba el comportamiento. Seguía igual.

Lo raro de esto es que con el SQL Server Management Studio la consulta es rápida, pero desde el lado del vfp demoraba bastante.

Gracias a todos.

Saludos.

Alcides Portillo

PD: Para Fernando D. Bozzo, la Base de datos que utilizo es del SQL Server, por lo tanto no afecta la tecnología Rushmore, la consulta se resuelve del lado del servidor y no del VFP, de todos modos gracias por tu aporte. 

[ZeRoberto]

Alci otra cosa que también me sucedió y lo soluciones es crear indices por los campos que condicionan la consulta, cuando los datos son bastantes se empieza a hacer lenta la consulta.

Saludos

--
btnMyVideo.Click()

[Fer]

Ahora te entiendo.
FoxPro también puede hacer ese tipo de consulta, que se llama asincrónica.
El problema en ese caso es que la ventaja que se le pueda sacar a poder ir viendo resultados de a poco se pierde en velocidad, por eso las consultas sincrónicas son más rápidas.
Igualmente me extraña que te tarde tanto. ¿de cuántos registros hablamos? ¿y que tamaño de registro? Porque del lado del cliente solo veo que puedan influir dos cosas, el diversos usado y la configuración que se use.
Aportá más datos, a ver si se puede ver la causa aparente.
Además de lo que te pregunté más arriba, poné el driver que usás y con que configuración lo estás usando.

[Luis Mata]

Hay que construir bien las consultas, muchas veces son errores nuestros, a mi me paso una consulta construida al guerrazo para salir de paso, demoraba casi 30 minutos, lo deje pero al final lo revise y la misma información con una select optimizado con indices, inner join, select(select).. bajo a menos de 1 minuto.

[Milton]

Cuando envías desde VFP a SQL Server una consulta mediante SELECT, por más sensilla que sea, esta tiene que compilarse. Se puede mejorar la velocidad de respuesta si pones el SELECT dentro de una función, y llamas de VFP a esta función mediante parámetros, de esta manera la consulta está siempre precompilada y el proceso de consulta será más rápida.

Ejm: Consulta lenta

= SQLExec(1,'SELECT * FROM Clientes FOR ClienteId=100' ,'Cursor')


Ejm: Consulta rápida

-- PRIMERO EJECUTAR ESTO EN SQL M.S.E
CREATE FUNCTION [dbo].[DatosCliente]
  (@ClienteId int)
RETURNS TABLE
AS
  RETURN
     ( SELECT A.*, B.GruInvNomb  FROM Clientes WHERE ClientesId=@ClienteId  )


* AHORA EJECTA ESTO DESDE VFP
= SQLExec(1,'SELECT * FROM dbo.DatosCliente(100)' ,'Cursor')

    Esto no necesita de compílatación, porque la FUNCION DatosCliente ya esta precompilada. De todas maneras me parece mucho tiempo el que tu indicas, puede intentar lo que te indico y mucha suerte.

Atentametne


MILTON

[ZeRoberto]

El tiempo de compilación no creo que le demore minutos, eso lo hace en nano segundos.

--
btnMyVideo.Click()

[Fer]

Tampoco hace falta llegar al extremo, las consultas externas  se pueden optimizar en fox de varias formas, por ejemplo precompilándola en Fox con sqlprepare y usando bind variables para no meter los datos directamente, sino con ?Var en los parámetros

[Fer]

Ojo, los tiempos de compilación sí que influyen, aunque tomen algo menos de un segundo (no son nanosegundos ni en el propio servidor), se notan y mucho cuando hay que realizar muchas consultas seguidas, por ejemplo en un proceso tipo batch.

[ZeRoberto]

Pero si la consulta en si demora 0.33 segundos entonces cuando demorara la compilación.

--
btnMyVideo.Click()

[Fer]

Puede que unas cuantas centésimas de segundo

[Carlos Miguel FARIAS]

SQL Server usa rushmore desde la versión 7. Una de las razones por las que M$ no suelta los fuentes de Fox.

Parece que ese tipo de algoritmo no se puede patentar o es difícil de probar robo de idea con algo equivalente.

Esto es lo que en algún lado se dijo, no se cuando ni quien cuando salio el SQL Server 7.
Saludos: Miguel, La Pampa (RA)

[David Salazar]

Como curiosidad porque no haces un procedimientos almacenado con tu consulta, le envias los parametros, y lo ejecutas desde fox, y ves los tiempos que tarda.

2013/8/5 Carlos Miguel FARIAS <carlosmig...@gmail.com>

[Luis Mata]

Esta es una buena idea, pero de todas maneras si la consulta esta mal construida o los índices están mal definidos no funcionaria.

[mpulla]

Hola Alci.

Puedes medir el tiempo que demora desde hacer el pedido hasta que te devuelve el resultado?

Como dice David, créate un SP y compara los tiempos.

Pienso que la diferencia debe ser minima, entre ejecutarlo en Sql Server Management y VFP.

Saludos.
Mauricio

[Alci]

El problema estaba en el filtro de la consulta, falto agregar el Código de la Empresa en el Where de la consulta, supongo que afecto el rendimiento como las claves son compuesta con campo código de la empresa (IdEmpresa).

No me di cuenta porque en la Base de Datos que estaba utilizando solo tengo cargado datos de una empresa, es por eso que los resultados eran correctos y no me di cuenta que falto el filtro de la empresa.

Después de agregar el filtro por empresa en la clausula where se normalizo.

Gracias a todos por su valiosa colaboración.

Saludos.

Alcides.

[Victor Manuel Thomas]

HOla  todos !  me gustaría saber si encontraron alguna solución, ya que tengo el mismo inconveniente, tengo una consulta de 300,000 registros que a su ves se convierten en 30 registros como resumen, igual en sql manage corre en 9 segundos pero desde el lado de fox se tarda 20 minutos, tengo creado un SP del lado del servidor que era bastante rapido al principio pero a medida a ah ido creciendo la data se torno lento la consulta del lado de fox, tengo VPF9 y SQL Server 2008 R2 Express.   cuenta con todos los indices necesarios pero por si alguien sabe de algo q pueda ayudarme.  

Por cierto probe con ODBC y efectivamente corre a la velocidad de SQL Manage pero ir a configurar ODBC a 50 equipos no tiene mucha gracia, menos cuando tienes que cambiar clave cada cierto tiempo.

saludos 

PD les dejo la la construcción del string, que funciona muy bien para tablas simples y reportes no mayores de 100,000 registros.

que a mas de uno se que le servira.

DRIVER=SQL Server

UID=sa

LANGUAGE=Español

DATABASE=midata

WSID=MIPC

APP=Sistema operativo Microsoft® Windows®

SERVER=servidor\instancia

Description=Conexion ....

[mpulla]

Hola Victor.

Traes 300,000 registros y los resumes en 30 ó la data es de 300,000 que los resumes en tu sp.

En todo caso 300,000 resgistros es poco.

9 segundos es mucho tiempo, seria bueno ver tu sp, tablas e indices a ver si te podemos aportar algo.

Saludos.
Mauricio

[Luis Mata]

No quieres instalar el ODBC en cada PC? pero al menos hasta W7 ya viene preinstalado los ODBC

[Miguel Canchas]

Y el codigo ¿?

 

 

MK

[mapner]

Fijate si tus tablas tienen campos BLOB  y los estás trayendo en la consulta.

El uso de campos BLOB enlentece mucho a la hora de traer datos por ODBC hacia VFP.

saludos

[MALKASOFT ADPI: http://www.developervfp.blogspot.com/]

Hola, te recomiendo que no uses Select * From, debes usar Select Campo1, Campo2 etc From, ahora aparte de index normales como pk y fk tiene que crear indices CLUSTERED o NO-CLUSTERED eso ara que tu consulta sea muy rápido cuando lo llames de cualquier herramienta de programación. te paso un link para que veas la diferencia http://grimpidev.wordpress.com/2008/03/08/diferencias-entre-clustered-y-non-clustered-index-en-sql-server/

Saludos; 

Ing. Russvell Jesus Soto Gamarra 

http://developervfp.blogspot.mx/

Framework Multi-conexion a cualquier base de datos v6.0

http://www.youtube.com/watch?v=PCCZvCaet74

Canal YouTube: http://www.youtube.com/rycjesusrj