Refrescar un DBGrid y que el puntero siga apuntando donde estaba
 

Hola foro:

Estoy haciendo un formulario que tiene un DBGrid, conectado a un Datasourse y este a Query1
En el Query1tengo algo parecido a:

"Select Nombre, Telefono, ID_Cliente from Clientes order By Nombre"

Esto me muestra en el DBGrid la lista de Clientes.
Luego en el evento Dobleclick del DBGrid muestro un formulario que me permite
Modificar el teléfono mediante un Query que tiene

"Update Clientes set Telefono=:P_Telefono where ID_Cliente=:P_ID_Cliente"

El problema es que luego de actualizar el teléfono, y cerrar el formulario de modificación, el DBGrid me sigue mostrando el telefono viejo.

Entonces luego hago:
Query1.Close;
Query1.Open;
Y entonces, el telefono se ve bién, El problema es que el puntero del DBGrid se hubica en la primer posición.

La pregunta es:

Cómo Puedo guardar la posición del puntero del DBGrid y cómo hago para hacer que apunte nuevamente al volver a abrir el Query1?
Estoy utilizando InterBase y Delphi 7.

Desde ya muchas gracias a todos po su atención.

Buscá la ayuda sobre las funciones para manipular bookmarks.

Su uso es mas o menos este:

Código Delphi [-]
var
  bkmk: Pointer;
begin
  bmkm := Query1.GetBookmark;
  try
    //hacer operaciones con el query
    Query1.GotoBookmark(bkmk);
  finally
    Query1.FreeBookmark(bkmk);
  end;
end;

Hasta luego.

;)

Listo
 

Sí, la solución propuesta fué correcta.
Muchisimas gracias

Está muy bien, pero no sé si alguien haya dado solución a esto:

1. Tengo un DBGrid que muestra resultados de una consulta a una base de datos Firebird.
2. Necesito reorganizar los datos de la consulta (lo hago haciendo click sobre el título de la columna)
3. Al dar click sobre el título de la columna modifico la cláusula ORDER BY de la consulta.
4. Cierro la consulta y la abro nuevamente.
5. Hasta aquí todo funciona muy bien.

Lo que sucede es que requiero que el cursor apunte al mismo registro en el cual me encontraba, para lo cual adopté primero esta solución:

, donde Id es una clave primaria.

Si la consulta retorna digamos unos mil registros, todo está bien, pero si la consulta es muy grande, al hacer el Locate puede suceder que el registro buscado esté casi al final o unos varios miles de registros después del primero, por lo cual el componente debe llevar al cliente los registros desde el primero hasta el registro buscado. Esto ocasiona demasiados "Fetch Next" que podrían ser miles, con las consecuencias consabidas: tráfico innecesario, y una demora sustancial que se puede contar en segundos y que podrían incluso llegar a minutos (me atrevo a decirlo por lo que tengo al frente).

Entonces decidí abortar este procedimiento. Cuál es la solución? Bueno, pues en este hilo se habla de usar Bookmarks, aunque claro está no para el mismo caso. Bueno, pues con estos, los Bookmarks, tenemos otro inconveniente, y es que prácticamente no sirven porque un Bookmark es un número de registro en el cliente (algo así como un RecNo o "registro número" N). Al dar click en la columna de título los registros devueltos vienen al cliente en un orden diferente, por lo que el registro número N (o en la posición N) ya no es el mismo de antes.

Observando el comportamiento del IBExpert para este caso idéntico, me doy cuenta de que esta aplicación ordena los registros y el cursor permanece en el mismo registro, sin demorarse prácticamente nada, lo cual quiere decir que en esta aplicación obviamente no se usa un Locate.

Entonces, cómo lo hacen? :confused:

PD 1. Estoy usando los MDO, y NO quisiera usar una TClientDataSet. Específicamente trabajo con un TMDOQuery. El TMDODataSet presentó problemas con el Locate y con el GotoBookmark.

PD 2. Quise realizar esta consulta en este hilo porque está relacionada con el título del mismo (cambiando el orden de los registros). No se si este hilo debiera pertenecer a los hilos de InterBase & Firebird, pero como involucra componentes... bueno, el caso es que ya estaba creado.

Si alguien ha trabajado en este caso, ya saben, gracias por sus comentarios al respecto.

Alto en el camino!
 

A veces no me siento muy bien. Me pregunto si sólo a mí me pasan algunas cosas, o si sólo yo decido adoptar ciertas soluciones que parecieran no ser muy adecuadas. Pero resulta que mis clientes trabajan sobre rejillas que muestran todos los datos de una consulta... están acostumbrados a ello porque vienen trabajando algunos desde hace años con versiones previas del mismo producto (pero que usan tecnología obsoleta). Entonces debo proporcionarles una nueva versión del producto, que adopte nueva tecnología, y que brinde la misma funcionalidad, especialmente para que ellos puedan realizar:

1. Búsquedas parciales con la posibilidad de mirar los registros anteriores y posteriores.
2. Filtros con base en las propiedades de los registros.
3. Selección de registros no consecutivos en la rejilla para realizar operaciones con estos registros.
4. Impresiones de todos los registros organizados por alguna de sus columnas.

Esto entre muchas otras posibilidades (por favor no sugieran cambiar el diseño, en serio no es adecuado). Bueno, todo en realidad funcionaba bien con pocos registros, pero cuando hice pruebas con consultas de varios miles de registros, incluso ya con mil registros, ejecutar un Locate es traumático. En entornos de producción se realizan filtros y se organizan los registros muchas veces. Como mencioné en otro hilo, no tuve inconvenientes con estas acciones cuando trabajaba con Paradox, pero resulta que sí los tengo al trabajar con Firebird.

Me pregunto si alguien ha trabajado a fondo estos asuntos... :confused:

... de ser así, ya saben. Muchas gracias por sus comentarios, sugerencias, recomendaciones, indicaciones, etc.

Este es otro hilo que, a mi manera de ver, trata el mismo asunto:

http://www.clubdelphi.com/foros/showthread.php?t=54209

En ese caso creo que la solución ya casi la tienes.
Si los clientes ya cargan todos los datos (no discutimos si eso está mejor o peor, ya que comentas que eso es así desde siempre) en tu caso el tema de la ordenación creo que deberías hacerla en memoria, en lugar de volver a lanzar la consulta y hacer la búsqueda posterior con locate.

Se me ocurre que puedes hacerla con un componente intermedio, como ya has comentado anteriormente, sea TClientDataSet u algun otro similar que te gestione esa carga en memoria o si no deseas ese componente te queda la solución de algun Grid que te lo haga; Ahora mismo estoy pensando en el Grid de las Quantum, que hace la función de Grid y de ese componente intermedio, almacenando TODOS los registros en memoria, por lo tanto las reordenaciones posteriores, agrupaciones, filtros y demás operaciones son casi inmediatos, puesto que todos los resultados ya están cargados y se gestionan el local.

Gracias por tu comentario... yo mismo había hecho referencia al TClientDataSet, y dije al respecto que no quisiera usarlo. Tengo una razón: Al momento de hacer la apertura, debo mostrar un mensaje al usuario para que espere mientras todos los registros viajan hacia él (el cliente). Hasta el momento he trabajado con tablas de unos 5000 registros... esto en realidad no es mucho, pero sí se siente el tiempo de espera.

Quiero decir que si es necesario usaré este componente, pero busco antes una solución más adecuada y quizá más profesional... una política propia con relación al desarrollo, ya que al optimizar procesos las soluciones en realidad serán amadas por los clientes.

En este mismo hilo yo me pregunto:

Eso es porque cuando ejecuto una consulta en IBExpert, no para el caso de las búsquedas pero sí para el caso en el que quiero mantener el cursor en el mismo registro al cambiar el orden de los registros, lo hace sin problema, sin demorarse prácticamente nada de tiempo, y sin tener que transferir todos los registros al cliente... eso simplemente se nota. Entonces significa que hay una forma de hacerlo sin tener que usar el Locate. Es lo que trato de averiguar.

Mi opinión al respecto es que no es óptimo darle a un humano 5000 registros en un grid, definitivamente no los procesará. Si realmente te interesa optimizar, debieras cuidar que una consulta devuelva solamente los registros que el usuario necesita/requiere y puede procesar. Yo diría que normalmente menos de 50, y como máximo un par de cientos.

Finalmente, comentar que hace mucho no uso IBExpert, pero si su "hermanito", IBManager, y este hace uso de QuantumGrid, que ya se ha mencionado en este hilo, para realizar los ordenamientos y por ende, para esta operación, trae todo el resultado a memoria primero.

Hasta luego.

;)

Bueno, a veces como dicen, hasta no ver, no entender. Yo entiendo lo que dices, y lo agradezco, pero en este caso es necesario. Voy a poner un ejemplo: te ha pasado que trabajes en una hoja en excel con muchísimos registros, con el propósito de organizar, modificar, seleccionar, imprimir, etc.? Bueno, es algo así. En la base de datos se almacena una gran cantidad de conceptos de evaluación, y la herramienta permite que el usuario haga este tipo de cosas, que si no es viendo, no es lo mismo y la tarea se hace más engorrosa. Es por eso que permitimos que nuestros usuarios tengan en frente de ellos las listas de conceptos que ellos mismos han creado.

Bueno, espero haberme explicado con relación al número de resultados en la rejilla.

Ahora, no uso QuantumGrid, sé que es muy buena, la he evaluado, pero no la usamos porque sencillamente no hemos podido comprarla, pero ya llegará el momento.

De todas formas, seguiré evaluando posibilidades. Si encuentro algo les cuento.

Gracias.

Bien, si de todas formas hay que mostrar todos los datos... el uso de ClientDataSet me parece aceptable. Lees todos los registros al entrar... con un pequeño cartel de espera (no debiera tardar tanto de todos modos), y luego con el ClientDataSet podes mantener indices en memoria y reordenar y reubicar registros muy, muy rápido...

Hasta luego.

;)

Como bien dices, es buena, pero no es mucho más rápida que TClientDataSet.
Como ya te han comentado, las "maravillas" que hace el Grid de las Quantum, se basan en que TODOS los datos estén en memoria.

Puedes desactivar esa característica y hacerlo que trabaje sin traer todos los datos, pero entonces pierdes caracteristicas como ordenación, filtros, agrupaciones, totales y subtotales,... (como es lógico).

Cierto...
 

Pues en este punto voy a dejar mi obstinación por querer encontrar una mejora al método 'Locate'. Por qué? Bueno, pues me rendí por un instante y quise probar el TClientDataSet, y efectivamente es muy bueno. La verdad no lo había usado antes, pero justo ahora estoy haciendo algunas implementaciones relacionadas con el ordenamiento, las búsquedas y los filtros. Con el ordenamiento me ha ido de "maravilla"... je je. Creo índices incluso compuestos, y prácticamente es inmediato, y las búsquedas funcionan de igual manera.

Muchas gracias por sus comentarios, y más a esta hora... :) (bueno, al menos en Colombia... son las 4 a.m.)

Luego quizá tenga tiempo para seguir profundizando en el método 'Locate' de los DataSet que he venido usando (por aquello que leía en la ayuda de que 'Locate' usaba el método más rápido haciendo uso de los índices si los había. En realidad, como mencioné antes en otro hilo, lo que hace 'Locate' es prácticamente desplazarse registro por registro. No sucede así cuando se usa con un TClientDataSet).