FoxPro/Visual FoxPro - consultas muy lentas URGENTE!!!

Hola a todos, espero que alguien me pueda ayudar con esto. Tengo mi sistema con sus reportes y consultas para mostrar por pantalla, realizados usando vistas locales o consultas select - sql into cursor. hasta hace un tiempo todo bien, pero mis tablas ya tienen alrededor de 600.000 registros y las consultas son LENTISIMAS.....Probe con un formularia cambiar por seek, found(), do while, etc y cambió notablemente la rapidez, pero eso significaría un trabajo enorme de cambiar codigo y crear cantidad de indices. Justamente yo use vista u consultas por que tenía entendido que era lo mas rápido.
Mando un ejemplo para ver si alguien me puede ayudar a ver si estoy cometiendo algun error o hay alguna forma de optimizar este procedimiento

*hago consulta de entradas menos salidas del dia que estoy consultando

SELECT mov_stock.fecha_mov, mov_stock.id_proveed, mov_stock.cod_art,;
SUM(mov_stock.entrada_u - mov_stock.salida_u) AS EXISTE,;
SUM(mov_stock.entrada_k-mov_stock.salida_k) AS EXISTE_k;
FROM gestion!mov_stock ;
LEFT OUTER JOIN gestion!comprob ON mov_stock.cod_cpte = comprob.cod_cpte ;
WHERE Comprob.mov_stock = 1 ;
AND Comprob.afecta_ex = 1;
and mov_stock.id_proveed =mprovee;
AND mov_stock.fecha_mov =mFdesde ;
group by mov_stock.cod_art INTO CURSOR cierre

Agradeceré cualquier sugerencia o ayuda URGENTE!!!!

proba lo siguiente, donde tenes el sigo "=" pone "==" (sin comillas)

Gabriela:
Creo que la forma en que estas abordando el tema esta correcta. es decir utilizar sentencias SQL y dejar de lado los SEEK y los FOUND.
Lo que yo realizaria en tu caso es crear un cursor y alli depositar los datos que cumplan una condicion determinada (rango de fecha,..etc) dejando algunos campos en blanco, stock final, etc (recuerda que el cursor puede ser ReadWrite). Posteriormente efectúo sobre ese cursor los calculos de saldo o lo que sea, poblando asi los campos en blanco.
Me da la impresion de que los calculos de suma en la instruccion SQL estan relentizando enormemente el asunto.
Ahora si todo ese codigo que efectua el proceso lo colocas en la base de datos como procedimiento almacenado, entonces ganaras mas velocidad aún.
Cuentame que te parece y como te resulta si es que decides aplicarlo.
Saludos
TITO

antes cuando trabajaba en tablas nativas (DBF) me cuidaba de no tener tablas grandes o de ser necesario usaba procedimientos incluidos.

usaba tabla de historia k no es mas que una copia fiel de la estructura de mi tabla original y en ella guardaba los datos con mas de un mes por ejemplo tu tabla de movimiento de inventario.
solo dejas el mes activo y lo demas lo envia a historia con la salvedad de tener una entrada inicial que tenga las sumas de todas las entradas y todas las salidas segun articulo
si necesitan un reporte con el movimiento completo entoces uno ambas tablas y le pongo un hermoso lotrero "busquese una coca con hielo y espere" antes de empesar el proceso asi entienden k tomara tiempo
y claro borro la entrada de resumen de mi data de trabajo

Gabriela, buenas tardes. Yo este problema lo solucionado de la siguiente forma y me ha funcionado.
* Adicionale un indice a tu taba donde solamente este la fecha peJ.
index on Fechadelatabla tag fechadelat (la sintaxis depende de como lo eses creando)
*
En el area de Set:

Set Reprocess To 0,0
Set Optimize On

Ante de tu consulta escribe este codigo:

Select AreadeConsulta
=Seek(FechadeConsulta)
*
Seguido la Sintaxis de la Consulta.
*
Select ....

*
Pienso q esto debería mejorar la generación de tu consulta.

Atte

Luis Alberto Bernal B.