Diferente efecto Refresh (TIBTable y TIBDataset) ¿por que?

[ronalg]

TEngo un problema, estoy "migrando" una aplicacion excrita en delphi 6
(IBX) y firebird 1.5; digo Migrando por no decir cambiando los componentes TIBTable por TIBDataSet, tengo una transacción para todo la aplicación, con los parámetros para "Read Commited", el problema es el siguiente.

Antes con TIBTable:
Insertaba un registro en una terminal de la red y al hacer refresh desde otra terminal (en la misma ventana) con el boton de la barra de botones me aparecia el nuevo registro inmediatamente, lo mismo sucedia cuando hacia un update en una terminal al hacer refresh en otra terminal que este en la misma ventana aparecian los cambios efectuados.

Ahora con TIBDataSet:
No me muestra los cambios en la tabla de una terminal a otra hasta que hago un commit (o commitretaing) en ambas terminales.

Esto me hace suponer que el refresh que hace TIBTable y el TIBDataSet deben hacer cosas diferentes, las preguntas son:

¿Por que funcionan diferente?
¿Cual la solución para que TIBDataSet se comporte como TIBTable solo en el refresh? (se me ocurre crear un disparador de enventos en firebird y abrir y cerrar la tabla cada vez que se capture el evento, pero esto me parece demaciado flujo de datos por la red)
¿Hay alguna forma de hacer el refresh solo del registro actual?

Y ya que estoy de pregunton como puedo hacer un fetch(10) con TIBDataSet osea traer registros de 10 en 10 desde el servidor, esto lo necesito para cuando se trabaja con tablas grandes o con tablas que traen campos blob con imagenes.

Mil gracias.

[Delfino]

Esto me hace suponer que el refresh que hace TIBTable y el TIBDataSet deben hacer cosas diferentes

supones mal, hacen lo mismo, tienes defecto o bien en la sentencia refrech del IBDataset (pon solo el primary key en la clausula where) o bien en las transaciones..

como puedo hacer un fetch(10)

con sql, select first .. te trae solo los primeros 10 pero no hay manera de traer los siguientes, en IB 7.0 y FB 2.0 esta la clausula Rows q permite hacer esto, o bien usa el componente Clientdataset q hace esto, incluso tiene metodos como FetchBlobs y FetchDetails q permiten personalizar el metodo del fetch, busca en bdn un articulo interesante sobre el tema..

N.B pq no usas el equivalente de los IBX para Firebird, los MDO..

[ronalg]

Despues de hacer unos experimentos con los TIBDataSet y los TIBTable, llegue a la conclución de que efectivamente hacen cosas diferentes básicamente encontre 2 cosas:

1. Los parámetros: los parámetros son utilizados implicitamente en todas las 4 sentencias (insert, delete, update, refresh), más claramente cuando defines algo como esto en la sentencia SQL "Inicial":
   

   Código SQL [-]
   select cod, nom, ap, am
   from tb_personas
   where cod=:codigo

   Las otras 4 sentencias la ser auto generadas no necesitan que se les especifique que lo que tienen entre manos es solo una parte de los datos gracias a where, es algo asi como si los datos fueran filtrados directamente al abrir la consulta y las otras cuatro sentencias trabajan directa y unicamente sobre estos datos filtrados.
2. Refresh o SQL refresh: Tiene una peculiaridad que en para el ahorro del ancho de banda de las red es muy interezante. Pongamos el caso de que refescamos una tabla, traéra de nuevo todos los registros desde el servidor y colocará el cursos al final de la tabla (esto es un "poco" <mucho> problemático en casos de bases de datos con gran cantidad de información) esto equivaldría a cerrar y volver a abri la tabla, en cambio la sentencia SQL refresh utiliza algo parecido a esto:
   

   Código SQL [-]
   select cod, nom, ap, am
   from tb_personas
   where cod=ld_cod

   ese "old_cod" hace la diferencia, y esta radica en que solo refrescará el registro atual sobre el que estamos trabajando y no los demas, ademas no mueve ni un milímetro la pocisión del registro como lo hace las tablas. es un poco incomodo a un principio y me estrelle contra este comportamiento, pero luego de meditar un momento sobre el POR QUE??? de este "ERROR", llegue a la conclución de que es muy útil cuando se trabaja en red, sobre todo si el volumen de la información a transmitir es mucha.