Ver Mensaje Individual
  #19  
Antiguo 27-12-2007
Avatar de Al González
[Al González] Al González is offline
In .pas since 1991
 
Registrado: may 2003
Posts: 5.604
Reputación: 30
Al González Es un diamante en brutoAl González Es un diamante en brutoAl González Es un diamante en brutoAl González Es un diamante en bruto
Smile

¡Hola de nuevo!

Cita:
Empezado por juniorSoft Ver Mensaje
...llamar al metodo mergechangelog o cancelupdates despues de aplicada la transaccion. dicho de otro modo, si puedo hacerlo pero no quiero hacerlo cada vez que tenga que hacer una ventana que se presente la misma situación. Me he decido por hacer el componente pero tengo la misma duda al respecto de en que momento llamar los referidos metodos despues que se aplique la transaccion...
Hay varias soluciones para esto. En lo personal empleo un sistema de objetos "save points" subordinados que reaccionan en cadena, pero no creo que sea necesario aplicar algo tan complejo en este caso.

En realidad no es demasiado el esfuerzo de escribir unos cuantos "dtXXX.MergeChangeLog; / dtXXX.CancelUpdates;" por forma, dado el beneficio que obtienes con la nueva implementación de ApplyUpdates, pero comprendo tu punto de vista bibliotecario: siempre puede hacerse más.

Como lo veo, tienes dos opciones relativamente fáciles de implementar:

1. Diseñar tus formas de captura bajo un esquema de herencia visual, colocando en tu "forma transaccional base" el código que será común para todas las formas de captura, incluyendo esto de las llamadas a MergeChangeLog y CancelUpdates (los "Commit / Rollback" del lado cliente). En ello podrás emplear bucles que recorran todos los conjuntos de datos usados por la forma (considerando que por cada uno tuvieses un TDataSource dentro de la misma).

2. Añadir un poquito más de código a tu nuevo método ApplyUpdates, haciendo que el conjunto de datos en cuestión (Self) se agregue a una lista global llamada "TransDataSets" o algo por el estilo. Cada vez que quieras cometer o revertir todo el grupo de conjuntos de datos involucrados en una transacción, sólo tendrías que recorrer dicha lista y llamar al método MergeChangeLog / CancelUpdates por cada elemento de la misma.

Te recomendaría más la opción #2. Y considerando que estás dispuesto a hacer de tu nueva clase un componente derivado (en lugar de una clase interpuesta), lo cual no es mala idea dada la importancia de la nueva funcionalidad, creo que, con el propósito antes mencionado, convendría crear también una clase TTransClientDataSets, derivada de TList o de TObjectList, definiéndole dos métodos para hacer el MergeChangeLog / CancelUpdates sobre todos los conjuntos de datos contenidos.

Espero te sea de utilidad y sirva de orientación. Te invito a publicar el código final de tus nuevas clases, para compartir en su totalidad esta interesante y muy útil experiencia orientada a objetos con nuestros compañeros.

Seguimos en contacto.

Al González.
Responder Con Cita