adhoc actualizacion de la cache de clientdataset

[juniorSoft]

saludos

a continuacion le describire mi problema tal vez algunos de ustedes han podido resolver tal situacion, mostrare solo las relaciones entre las tablas que
ejemplifican el problema

tengo las tablas

ventas

detventas

detallesdepago

ingefectivo

ingtarjeta

ingcheque


todo me funcionara muy bien si solo fueran las tablas ventas y detventas
tengo todo configurado en el servidor de capa intermedia para estas tablas
pero lo que me planteo hacer es que al momento de el cliente realizar el pago
halla un grid conectado a la tabla detallesdepago el cual se puedan hacer diferentes tipos de pagos para completar el total de la factura mediante una ventana que se despliege y se vallan eligiendo los tipos de pago e introduciendo sus montos hasta completar el total de la factura. introduciendo datos en las tablas de ingefectivo, ingtarjeta o ingcheque
y que se valla actualizando la tabla detallesdepago tambien en la cache
hasta que se le de al boton guardar


entoces los campos que interesan son los siguientes de estas tablas

ventas
idventa
.
.

detventas
iddetventa
idventa
.
.

detallesdepago
iddetpago
idtipoentidad
identidad
.
.
.

ingefectivo
idingefectivo
iddetpago
.
.
y las tablas
ingtarjeta y ingcheque con los campos parecidos a ingefectivo mas sus campos especificos como portador, notarjeta etc.

entonces detallesdepago se relaciona con ventas por el campo identidad
el campo idtipoentidad me identifica el tipo de relacion a la que se refiere en este caso es ventas, lo hago asi por que hay mas tablas relacionadas con detallesdepago y no quiero crear campos nulos para diferentes tipos de situaciones

entonces lo que quiero hacer es un metodo remoto que sea el encargado de actualizar los datos que tienen los clientdataset en su delta, haciendo la relacion Master detail en el modulo cliente asi podria aprovechar los componentes sql que estan en el servidor de capa intermedia para las restantes situaciones faltantes


se que tendre que ocuparme de poner el codigo dentro de una transacion
manipular los errores que se puedan genera entre otros tal vez algunos de ustedes tienen algun ejemplo parecido que me pueda servir de ayuda

espero no haber aburrido mucho con tantas palablas para explicar lo que quiero y que ademas me hayan captado la idea, pero muchas gracias por su atencion.

[[Al González]]

Te invito a que nos plantees el problema de la manera más simplificada posible (sin perder claridad). Digamos, con dos o tres tablas solamente, y dándonos un "ejemplo de pizarrón" para comprender mejor lo que buscas.

Gracias.

Al González.

[juniorSoft]

he estado buscando documentacion en varios sitios

y me ha llegado una idea


para simplificar mas la explicacion de lo que quiero hacer

es solo crear un metodo remoto en la capa intermedia que sea el encargado de mandar las actualizaciones al servidor sql del contenido de la cache de los clientdataset en vez de utilizar el metodo applyupdate en la capa cliente de dicho componente ya que hay demasiadas relaciones complejas entre tablas. y queria envolverlas todas en una transaccion. Sé que el componente provider envuelve en una transaccion los datos que se envian del clientdataset al ejecutar el metodo applyupdate pero eso es solo si todas las tablas estan relacionadas en la capa intermedia.

para que me comprendan mejor

supongamos que tengo una funcion llamada serv que ya me devuelve el servidor de capa intermedia para poder ejecutar los metodos remotos entonces seria

serv.actualizardatos(clientdataset1.data, clientdataset2.data... )

y que sea ese metodo el que se encargue de la actualizcion

y muchas gracias por su interes...

[[Al González]]

Hola Juniorsoft, creo que ya entendí el punto.

Me he topado con la misma inquietud y por ello hace poco terminé la versión alfa de un derivado de TClientDataSet con el que puedes hacer un ApplyUpdates "transaction-aware" (para esas ocaciones en que uno quiere manejar varios conjuntos de datos en una sóla transacción).

Pero analicemos el problema por la vía de una solución totalmente nativa, considerando este seudocódigo:


StartTransaction

dt1.ApplyUpdates
dt2.ApplyUpdates
dt3.ApplyUpdates

If todo bien Then
Commit
Else
Rollback


Dinos, ¿cuál es el problema concretísimo que te surgiría con esta organización de instrucciones?

[juniorSoft]

ok

cuando yo tengo clientdataset anidados maestros- detalles relacionados en el modulo de datos remoto es facil manejar la transaccion de varios dataset ya que el clientdataset maestro me trae los campos de tipo dataset que se relacionaron en los componentes sql del modulo remoto y la transaccion por defecto del provider los envuelve a todos e incluso puedo llamar storeprocedure dentro de los eventos del provider y estos quedan envueltos tambien en la transaccion.

Pero lo que quiero hacer es un formulario pequeño que me maneje los tipos pagos ya sea en efectivo, cheque o tarjeta y que este formulario me sirva no solo para las ventas sino que tambien me sirva para otros mantenimientos como por ejemplo cuentas por cobrar sin tener que hacer nuevas relaciones de las mismas tablas para el mismo proposito, aclarando que para hacer un pago se pueden utilizar los tres tipos de pago para completar el total a pagar y es donde entra en juego la tabla detallesdepago que tiene una relacion uno a uno con estos tipos de pago. si hago la relacion directa en el modulo de datos remoto por ejemplo con ventas, ya no podre utilizar esos mismos componentes sql para utilizarlos en la relacion con cuentas por cobrar.

si se pueden separar los applyupdates uno para la factura en si y otro para los pagos pero que queden envueltos los dos en una misma transaccion como el ejemplo que escribiste

si has chequeado en la cara oculta de delphi 4 en el capitulo de midas su autor escribio un ejemplo para delphi 3 de un metodo remoto que es el encargado de actualizar los datos para envolver en una transaccion por que los clientdataset tienen envuelta la transaccion a partir de delphi 4

gracias por tu ayuda...

[[Al González]]

Hola de nuevo.

Empezado por juniorSoft

...si se pueden separar los applyupdates uno para la factura en si y otro para los pagos pero que queden envueltos los dos en una misma transaccion como el ejemplo que escribiste...

Bueno, estrictamente hablando, las "aplicaciones al servidor" de los dos conjuntos de datos sí quedan envueltas en la misma transacción aunque ellos no estén relacionados entre sí.

La duda que tengo sobre tu planteamiento es:

1. Si no sabes que desde tu aplicación cliente puedes controlar el inicio y cierre de la transacción, evitando que eso lo haga de manera implícita un componente proveedor, y con ello poder envolver en una transacción varios conjuntos de datos no relacionados entre sí (aunque esto depende del modo en que se configure el servidor de aplicaciones).

2. Si, conociendo esa capacidad, te preocupa entonces lo que pasa con la memoria de los conjuntos de datos que sí lograron aplicar los cambios de manera exitosa, cuando la transacción tuvo que ser revertida (rollback) debido a un subsiguiente conjunto de datos que no logró hacer sin errores su ApplyUpdates.

Todo lo que has planteado está muy completo, y ayuda a entender muchas cosas, pero sigue quedando un poquitín abstracto. Tomemos dos conjuntos de datos clientes llamados dt1 y dt2, los cuales están enlazados a diferentes proveedores de la capa intermedia (no están relacionados como maestro-detalle).

¿Qué problema te representa que lo hagas de esta manera?

Código Delphi [-]
  Serv.IniciarTransaccion;

  Try
    dt1.Append;
    dt1.FieldByName ('A').Value := 1;
    dt1.Post;

    dt2.Append;
    dt2.FieldByName ('A').Value := 1;
    dt2.Post;

    If (dt1.ApplyUpdates (0) = 0) And (dt2.ApplyUpdates (0) = 0) Then
      Serv.CometerTransaccion
    Else
      Serv.RevertirTransaccion;
  Except
    If Serv.EnTransaccion Then
      Serv.RevertirTransaccion;

    Raise;
  End;

Yo veo uno. El de que si falla dt2.ApplyUpdates y se revierte (rollback) la transacción, podrás revertir también la memoria de dt2 (con su método CancelUpdates o su propiedad SavePoint). Pero a dt1 ya no lo podrás regresar a su estado previo debido a que ya limpió el "ChangeLog" por no haber tenido errores su respectivo ApplyUpdates. Solución típica y nada eficiente: refrescar dt1. Y esa es una de las razones por las cuales he estado trabajando en el TMagiaClientDataSet (un derivado con ciertas capacidades transaccionales).

Pero no estoy seguro sí esto te preocupa a ti también, o es otra cosa de menor, igual o mayor importancia. Esperamos tus comentarios.

Un abrazo que no se revierte.

Al González.