No es concretamente lo que buscás pero te paso una porción de un post de Jason Wharton en otro foro:
Cita:
Rollback retaining is quite a bit more difficult to implement than
CommitRetaining. It is especially more difficult to respond to on the client
if record buffering is going on.
By doing a CommitRetaining you are ensuring that which is in the client
buffers matches what is the committed state on the server. Thus, as a result
of it the client and server are in sync with eachother. This is easy to deal
with.
When a RollbackRetaining is performed this causes the server to disregard
all the data manipulation requests that the client has made. This causes the
current state of the buffers to become out of sync with the server. Not os
easy to deal with.
What needs to happen to make this work is one of two things. Either the
client refreshes all of its datasets (in which changes were made since being
opened) after the RollbackRetaining is performed so that they are back in
sync or the client needs to keep track of every change that has been made
and then effectively reverse those changes item by item in the buffers. Or,
it could selecitively refresh just those rows affected. As long as triggers
have done furthur changes the client and server would be back in sync.
|
Otro enlace de interés:
http://delphi.weblogs.com/stories/storyReader$379
Personalmente, y por consejo de MUCHA gente, he decidido no utilizar la retención de las transacciones para dar paso directamente al commit y al roolback.