[[Al González]]

Hola de nuevo.

Esto puede ser de alguna utilidad.

Haciendo más pruebas encontré que este defecto tiene cierto patrón. Ocurre solamente con registros nuevos (creados en memoria y aún no aplicados al servidor), que pueden o no tener modificaciones tras haber sido guardados en memoria (con o sin ediciones tras el primer Post). Pero NO ocurre si el registro en cuestión es el último en la lista de cambios (change log) del conjunto de datos.

Es decir, aparentemente, si el nuevo registro es la última operación realizada entre todas las altas, bajas y cambios que están pendientes de ser aplicados al servidor, RevertRecord funcionará sin conflicto alguno con el filtraje usado, eliminando el nuevo registro de la memoria del conjunto de datos y de su lista de cambios.

Los siguientes son cinco ejemplos de listas de cambios en el orden en el que son hechas las operaciones.

Ejemplo 1:
Alta A
Alta B
(puede ser revertido B, pero no A)

Ejemplo 2:
Alta A
Alta B
Baja C
(no puede ser revertido ni A ni B)

Ejemplo 3:
Alta A
Alta B
Cambio B
(puede ser revertido B, pero no A)

Ejemplo 4:
Alta A
Alta B
Cambio C
(no puede ser revertido ni A ni B)

Ejemplo 5:
Alta A
Alta B
Baja C
Cambio A
(puede ser revertido A, pero no B)

El remedio de llamar al método Delete con los registros nuevos para evitar el problema, si bien puede resultar una solución práctica, tiene el inconveniente de que mantiene el registro invisible ocupando memoria en la lista de cambios, sin hablar de los eventos y otras acciones llevadas a cabo por el método Delete.

Se me ha ocurrido que puede reemplazarse el método RevertRecord nativo por uno que haga lo mismo, pero que, cuando el registro sea nuevo, revise si éste se encuentra hasta el final de la lista de cambios (para ello puede utilizarse un cursor clonado con la propiedad StatusFilter llena), y, en caso de no ser así, lo modifique silenciosamente (sin disparar eventos), forzándolo a quedar al final de la lista de cambios antes de ejecutar la reversión.

Grosso modo, algo como:

Código Delphi [-]
Procedure TMyClientDataSet.RevertRecord;
Begin
  ...
  If RegistroEsNuevoYNoUltimoCambio Then
  Begin
    UpdateCursorPos;

    // Limpiamos un campo para provocar el cambio
    Check (DSCursor.PutField (ActiveBuffer, NumeroDelPrimerCampoNoVacio,
      Nil));

    { Guardamos el registro modificado en la memoria del conjunto de datos
      sin actualizar los buffers de registros (la interfaz de usuario no se
      entera) }
    Check (DSCursor.ModifyRecord (ActiveBuffer));
  End;

  Check (DSCursor.RevertRecord);
  ...
End;

Lo sé, después de ver todo esto, la solución de usar un simple Delete no parece tan mala, pero lo aquí planteado puede llegar a servirle a alguien.

Finalmente agradecería cualquier prueba que puedan hacer en Delphi 2009 o 20010. Por cierto, tengo entendido que ésta última trae el código fuente de la unidad MidasLib. En ella podría estar la clave de este defecto del método RevertRecord de la interfaz IDSCursor.

¿Alguien se anima a participar en esta investigación? Yo la dejaré hasta aquí por ahora.

Saludos.

Al González.