¿No puedes activar el límite de 400 cuando no haya filtro activo?. Supongo que no, pero entonces, ¿para qué implementar ese límite si no puede ser usado cuando más falta hace? ]:-D (el emoticon del diablillo me encanta).
Cita:
|
La primera vez que se hace la query y se muestra el grid es casi inmediato. Luego cuando se empieza a filtrar o se vuelve de la pantalla de altas/modificaciones, es cuando va pintando los registros en el grid de uno en uno (a toda velocidad) pero al ser los 4000 o 5000 tarda bastante.
|
Me da a la nariz, que hay algún código recorriendo todo el dataset. El DBGrid, solo pinta en pantalla las líneas que se ven en su
área visible, las ocultas (porque hay que hacer un scroll vertical y/o horizontal),
esas no las pinta).
El código a que me refiero, incluso puede que lo haga el propio DBGrid (si es un componente de terceros) por ejemplo, para ajustar el ancho de las columnas. Si este es el caso, un Dataset.DisableControls y Dataset.EnableControls quitaría ese "tiempo de repintado".
Los campos más frecuentes de búsquedas, si deberían tener un índice. Al realizarse los inner joins por clave primaria, se está agilizando la unión en memoria de las tablas involucradas, pero si buscamos el cliente de nombre 'pepe' las claves primarias no sirven para encontrar al sujeto, hay que recorrer toda la tabla comparando si el nombre es 'pepe' o no. Estableciendo un índice, se tiene ordenado (en el índice) todos los nombres de los susodichos
y dicha búsqueda, hará uso del índice.
Ten en cuenta que los índices deben actualizarse cuando hay inserciones/borrados por tanto, tampoco se debe crear un índice en todos los campos de la tabla.
Saludos