adhoc actualizacion de la cache de clientdataset

[[Al González]]

Hola Maniche.

Hoy matizaría un montón de cosas de aquellos mensajes míos, pero en esencia fue y sigue siendo posible hacer que varios conjuntos de datos clientes conserven su "bitácora de cambios", aun después de aplicar éstos al servidor de forma exitosa (lo normal o "nativo" es que una vez aplicados se borre esa bitácora).

Lo que le planteaba a juniorSoft (a quien le mando un saludo) funciona con DataSnap, pues TClientDataSet, MIDAS, forma parte de DataSnap (si bien el puro componente TClientDataSet sirve para más cosas).

Pero en esto de las bases de datos hay cierta buena práctica que se valora con el tiempo y a la cual uno debe intentar orientarse (aunque a veces cuesta trabajo o no gusta): Que el inicio y el cierre de una transacción de base de datos no dependan de diferentes órdenes o envíos de la aplicación cliente, sino que una sola orden del cliente sea el desencadenante tanto para abrir la transacción, como para grabar los cambios y cerrar la transacción. Esto es una de las diversas razones para tener una "capa intermedia", un programa normalmente sin interfaz de usuario llamado servidor de aplicaciones que, instalado en una computadora respetable y poco propenso a mal funcionamiento, sirve de apoyo al motor de bases de datos, programa al que sí le damos el derecho de abrir y cerrar transacciones abiertamente.

DataSnap facilita enviar "todo en un paquete", para que se cumpla el que sea una sola orden del lado cliente la desencadenante de toda la transacción, esto cuando se usan conjuntos de datos "anidados" (nested data sets), pero hay que subrayar que ese esquema está pensado para los casos donde todos los conjuntos de datos de la transacción están organizados en un árbol de relaciones maestro-detalle (a no ser que se quiera abrir y cerrar la transacción explícitamente desde el cliente).

Mi necesidad de que pudiera aplicarse un esquema "transaccional" a varios conjuntos de datos que no necesariamente estuviesen relacionados entre sí, fue lo que me llevó a estudiar y redefinir los métodos de TClientDataSet que menciono en los mensajes anteriores del hilo. Pero si bien soluciona esa necesidad de manejar cambios de tablas diversas en una sola transacción, pierde una pieza importante: que el servidor de aplicaciones evite abrir la transacción (y por tanto no empiece a guardar datos) antes de que el lado cliente termine de enviarle todos los cambios de todas las tablas involucradas.

Cómo recuperar esa pieza que se pierde por no usar conjuntos de datos anidados es algo que me interesa estudiar, y creo que todas las ideas que se tengan son bienvenidas (se me ocurren cosas como usar el OwnerData de un único ApplyUpdates, o dotar a los TDataSetProvider con la capacidad de "retener" los cambios) .

Por lo pronto, Maniche, si fueras tan amable de exponer con detalle y claridad tu interés en el tema para ver qué solución podría ser la más adecuada...

Saludos.

P.D. canelita, perdona por no responder en su momento. TClientDataSet tiene bastantes cosas sobre las que se puede profundizar. Aquí en el foro hay varios hilos que tratan sobre esa clase y no se diga la cantidad de páginas Web que explican algunos de sus más útiles aspectos. Si lees esto nos dirás si todavía buscas documentación o en el mejor de los casos nos compartirás algunos enlaces hacia lo que hayas encontrado.