Consulta sobre TQuery...
 

Hola a todos,

antes de nada, decir que la forma más óptima de hacer lo siguiente está claro que no es la que voy a poner, pero estoy buscando una solución sencilla al problema.

La historia es la siguiente. Tengo un mantenimiento de artículos, se hace una query con varios join y se mete en una DBGrid. Luego sobre ese grid se pueden dar altas y hacer modificaciones, cuando esto sucede nos sale otra pantalla en la que lo hacemos y en esa misma se lanza un insert o un update del artículo con lo que en Base de Datos ya está correctamente pero no en el interfaz gráfico, al volver al grid se hace un close y un open de la query para que refresque. Ahí es donde está el problema ya que cuando la tabla tiene miles de registros tarda bastante en volver a sacar toda la información en el grid.

Y aquí viene mi pregunta...hay alguna forma de modificar un registro de una Query o estas son de sólo lectura y no se puede hacer de ninguna forma?

Algo tipo: Query.FieldByName('Nombre').AsString := 'dfgd';
(después de habernos situado en ese registro).

Si no es así, hay alguna forma muy sencilla de resolver este problema sin acudir al request live de las querys?

PD: Está hecho con BDE por si sirve de ayuda.

Un saludo.

hay una propiedad llamada RequestLive, colocoala a True, pero si la consulta involucra varias tablas no vas a poder hacer lo que quieres...

Ya, eso es lo que decía, no obstante en realidad sí se puede (o eso creo) poniendo un UpdateSQL en el UpdateObject del TQuery y dándole ahí las instrucciones sobre lo que tiene que hacer en el insert, update...pero quiero ver si hay alguna forma de "engañar" al TQuery y modificar directamente la parte de la memoria que quiero.

Otra opción sería hacer un close y un open de sólo el registro que he modificado, es decir hacer una especie de refresco del select de sólo una parte de la tabla...

Alguna ídea más??

Se puede hacer algo así o es imposible??

Salu2.

Más opciones aparte de las que tú mismo ofreces... creo que no hay.

Lo realmente interesante es preguntarse:
¿realmente necesito esos miles de registros en el Grid?
¿realmente le ayuda al usuario ver un grid con miles de registros para localizar el registro que él quiere?

PD: Al decir "miles" no se tiene idea de cuantos son, yo al menos con 5.000 registros y usando Firebird, antes de pestañear ya tengo los registros, ¿tienes índices creados por los campos de búsqueda?

Saludos

Hola Lepe, gracias por la respuesta.

En la aplicación existe una variable de configuración que lleva el número de registros mostrados en el grid, así que no es algo que suela pasar, ya que está puesta a 400 o 500 normalmente, pero si por ejemplo se filtra y se deja todo vacío saca 4000 registros y es en ese momento cuando tarda.

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.

La base de datos está en sqlserver 2000 y las tablas tienen su PK y sus FK definidas correctamente.

Cuando me dices lo de crear índices por campos de búsqueda, creo que en este caso no ayudaría mucho no? ya que siempre se está buscando (haciendo las join) por pk o fk y el resto de los campos q se sacan no aportarían nada teniendo índices no?

En cuanto a las preguntas de:
¿realmente necesito esos miles de registros en el Grid?
¿realmente le ayuda al usuario ver un grid con miles de registros para localizar el registro que él quiere?

tienes toda la razón, no es para nada necesario, de hecho con visualizar el que van a modificar en el grid o los últimos cuando están haciendo altas valdría, pero a veces los usuarios filtran y sacan miles de registros (unos pocos ;)) y es ahí cuando a la vuelta de modificar el registro tienen el problema (que por otra parte se han buscado ellos solitos). No obstante, y dado que eso no lo podemos controlar, quería ver si había una forma muy sencilla de engañar a los TQuerys de Delphi tratándolos como datasets normales en los q poder escribir pero ya veo q mis sospechas se confirman :)

Muchas gracias de todas formas!

Un saludo.

¿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).

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

El límite que está configurado en las opciones es el que se usa si no hay ningún filtro activo. Lo que quería decir es que si le das a filtrar y no pones nada en los campos que tiene, lo que hace es sacar todos los registros de la tabla.

Por otra parte, en cuanto a los filtros qu se utilizan, todos tienen índices, ya sean PK o FK.

En cuanto a lo de que hay algún código recorriendo todo el dataset, tienes toda la razón, no había caido, por eso se recorre todo el grid, ya que está pintando las filas de un color o de otro según un determinado valor cada vez que se vuelve a esa pantalla. Eso es lo que más ralentizaba...una cosa ta tonta y no había caido...:)

Un saludo y muchas gracias Lepe.