Hola Amigo AL,
Muchas Gracias por tomarte un tiempo y por ser muy claro en tus respuestas.
Para iniciar mis comentarios voy a comentar parte por parte tu respuesta amigo AL, pero inciar comentando:
Cita:
|
El Caso que he comentado y he detallado se ha implementado en un compañía grande con bastante concurrencia de información. Por ello se implemento el tener que crear arreglos de Provider y Deltas y estos enviarlos al servidor en una sola transacción y que la actualización hacia el cliente sea transparente, utilizando los deltas enviados al servidor y que estos me permitan actualizar en cache de los ClientDataSet.
|
Les comentaba a los amigos que es muy importante esto ya que a cualquiera se le puede presentar módulos que impliquen muchas tablas anidadas y relacionadas como era el caso que expongo y se complicaba mas cuando tienes 1000 a 2000 usuarios ONLINE golpeando toda esa lista de tablas.
Cita:
|
Cuando implementamos la solución esta programado de la siguiente manera: Servidor(ADO Components, Providers) Cliente(DCOM, ClientDataSets, Datasource) Claro que esta arquitectura usa MIDAS, un poco preparándose y evitar la problemática de no tener soporte de DCOM en los nuevos Windows es que decidí hacer la migración de este método a DATASNAP con DXE3
|
Yo he avanzado gran parte de la migración por ello que he puesto un ejemplo en el HILO que les permita ver mejor a mas detalle lo que se esta comentando. Claro que el ejemplo esta con una sola tabla y si se resuelve ya lo demás es sencillo.
Aquí mis comentarios a tus respuestas amigo AL:
Cita:
|
Primero aclarar que Delta es, como dice la ayuda de Delphi sobre la propiedad TClientDataSet.Delta: un paquete de datos del registro de cambios...
|
Si amigo me referia al Delta del Cliente que este se envía al servidor para actualizar los cambios. ten presente que no se envía directamente desde el componente (TClientDataSet.Delta) se hace mediante un arreglo de Variants y todo el paquete es un OLEVariants.
Cita:
|
En segundo lugar, debes saber que el método TClientDataSet.Reconcile tiene como propósito limpiar el registro de cambios del conjunto de datos después de que su Delta fue enviado al servidor con ApplyUpdates...
|
Muy cierto lo que comentas con respecto a RECONCILE. eso es lo que se quiere hacer de las 10 a 20 tablas actualizadas limpiar los registros de cambios. An la arquitectura anterior mencionada lo soportaba sin problemas. En el ejemplo esta el método
ReconcileDeltas que debería hacer eso y es el que trae problemas. Ya que como decía muestra el error: "Mismatch in datapacket."
Cita:
|
El mismo método ApplyUpdates se encarga de llamar a Reconcile cuando el servidor rechaza alguno de los cambios. Reconcile tiene varias formas de tratar con esos cambios...
|
Muy cierto tus comentarios, ya que los eventos que mencionas se ejecutan cuando hubo un problema en la actualización sino simplemente quita el registro de cambios.
Cita:
|
Reconcile y OnReconcileError no sirven para "refrescar" los registros que tiene en memoria el conjunto de datos cliente. No es ese su propósito...
|
Es verdad lo que mencionas. Pero como la actualización no se esta haciendo usando el método ApplyUpdate del componente ClientDataSet. es por ello que en el ejemplo lo esta haciendo después de haber actualizado en la base datos para quitar los registros de cambios de los CDS. El detalle que hay algo que no esta permitiendo que se pueda realizar el RECONCILE.
Cita:
|
Imagino que no ha de ser imposible canalizar esa devolución del servidor hasta la aplicación cliente, para que ésta actualice su "caché" de registros (TClientDataSets), ya que tanto TDataSetProvider como TClientDataSet posibilitan la transmisión de todo tipo de información...
|
El problema no se esta presentando cuando se hace directamente con los componentes. Ten presente que todo esta en Arreglos Variants y toda la información se envía como OLEVariants
Cita:
|
Pero antes de intentar ese camino, considera que hay por lo menos otra forma en que un conjunto de datos cliente puede refrescar los registros que ha enviado al servidor, sin tener que hacer un completo Refresh o Close + Open...
|
Es muy cierto que hay otras formas como lo mencionas, Voy a revisar el Hilo que me has compartido ahí te comento. Como se esta hablando que hay varios Datasets implicados el hacer otros caminos va a demandar mas trabajo y no necesariamente puede cubrir para la optimización que se desea.
Voy a hacer unas pruebas y les comento.
Cita:
|
Cierto, eso supone volver a hacer una consulta al Servidor, pero al menos no traes de él todos los registros que ya tienes en memoria, sino solamente los que acabas de mandar, reduciendo significativamente el peso de la solicitud...
|
Como les comentaba el metodo estaba funcionando bien, claro con otra arquitectura. Pero si no es soportado por DATASNAP. No me va a quedar otra que definir Datasets en paralelo con sus parametros correspondientes por PK y traer la lista de registros que tan solo han sido Insertado/Modificados/Eliminados eso ya seria como ultima alternativa y cuando ya me quede sin cabellos... jejeje una broma
Espero haya aclarado un poco mas mis comentarios y estamos comunicandonos amigo AL.
Amigos del Foro siempre es bueno recibir consejos, sugerencia y aportes de las amigos que capaz ya se hayan enfrentado a algo similar.
Saludos a Todos un buen fin de Semana.
