Evitar un locate

[Kafu]

Hola foro,

Estoy usando dbgrids atados a tibdatasets para mostrar tablas que pueden ser relativamente pesadas.
Quiero implementar una búqueda y me encuentro con un problema:
La ventaja que me da el tibdataset es que la operación fetch se reduce al número de registros que veo en pantalla (corregidme si me equivoco). Sólo cuando hago un ctrl+fin tengo que hacer un fetch de toda la selección, que suele coincidir más o menos con la tabla.
Aunque no puedo evitar esto, me pregunto si a la hora de posicionarme en un registro hay forma de que no me lea todos los que están entre el origen y el destino.
Imagino que si uso el locate me ocurrirá lo mismo, iré leyendo todo hasta localizar el registro.
No sé si será posible hacer algún select que se posicione en un registro dado directamente, a mí no se me ocurre, pero si hay alguna alternativa al locate me gustaría conocerla.
El problema es que no quiero limitar el rango de registros que debe devolver el select, sino simplemente cambiar la posición.
Bueno gracias por adelantado por cualquier idea que se os ocurra. Un saludo,



F.T.G.

[__hector]

En una base de datos relacional, si tienes un recordset de 100 registros, no es posible posicionarte en el 50 sin haber recorrido los primeros 49. Esto porque la ubicacion fisica de los mismos no va necesariamente en secuencia, sino que cada registro tiene un dato "relacion" o apuntador al siguiente, asi que tienes que irte saltando uno a uno para llegar al que quieras.

[haron]

eso que dice hector es cierto.
en la siguiente consulta

select * from tabla

no tiene sentido decir 'el ultimo elemento', ya que es un conjunto de datos sin un orden determinado, por lo que al programa no le queda mas remedio que ir cargandolos de uno en uno.

sin embargo creo que una tabla (TIBTable) no lanza una consulta de este tipo, si no la siguiente:

select * from tabla order by clave_primaria

en este caso sí tiene sentido hablar del ultimo elemento y el componente data-aware es lo suficiente inteligente como para lanzar la siguiente consulta:

select * from tabla order by clave_primaria desc

luego va rellenando las filas del grid en orden descendente, sin necesidad de pasar por todos los registros anteriores.

parece que si te quieres mover libremente por un conjunto de datos grandes es mejor usar un componente TIBTable que un componente TIBQuery.

esto que te he dicho es cierto para los componentes del BDE. en el caso de los componentes de la paleta Interbase no lo he probado. lo mejor sera espiar la comunicacion cliente / servidor instanciando un componente IBSQLMonitor y ver que esta pasando.

[Kafu]

Bueno primero gracias por vuestras respuestas. He probado con el ibsqlmonitor y efectivamente la primera vez que hago un locate se hace un fetch de cada uno de los registros que hay entre el origen y el destino.
Las pruebas las he hecho con el primer y último registro. Pero después de haber leido todos los registros los nuevos locates no piden más al servidor, así que genial. Ese primer locate puede ser un poco lento, ahí está la pega. Cada vez que reordeno se modifica la propiedad Selectsql del tibdataset y el primer locate sigue teniendo que enfrentarse al tráfico de red.
Y realmente tampoco me conviene tirar de tabla a no ser que refresque cada poco tiempo, porque interesa que los datos estén lo más actualizados que sea posible.
No sé si esto se podrá optimizar, sigo probando. Gracias y un saludo,




F.T.G.