[pkcito]

Entiendo que hay un problema de transacciones. No puedo asegurarlo sin tener más información.

Cuando se ejecuta el método ApplyUpdate del ClientDataSet los datos originales (los que se obtuvieron de la base de datos) y las modificaciones se empaquetan y se pasan al DataSetProvider. Dependiendo de su configuración, el DataSetProvider puede aplicar los cambios de dos formas: generando sentencias INSERT, UPDATE y DELETE (lo que hace por defecto) o actualizando los DataSet usados para obtener los datos. Asumo que la configuración del DataSetProvider no se ha modificado y se están generando sentencias INSERT, DELETE y UPDATE.

En el proceso que aplica los cambios se verifica si ya hay una transacción activa. Si la hay entonces no se hace StartTransaction ni Commit. Si no la hay entonces se hace StartTransaction y luego Commit. Está claro que en este caso hay una transaccíon activa y, si bien los cambios son aplicados en la base de datos, no son visibles fuera del contexto de la transacción activa. Al cerrar la conexión con la base de datos, y esto también depende de la configuración, la transacción activa es finalizada automáticamente con Commit.

Lo más probable es que sea el propio DataSetProvider el que inicia la transacción y la mantenga activa. Cuando el DataSetProvider no le pasa todos los registros disponibles al ClientDataSet (esto depende de la propiedad PacketRecords del ClientDataSet) entonces el DataSet que usa el DataSetProvider para obtener los datos permanece activo y su transacción asociada también.

Para solucionarlo de una forma más elegante (en vez de cerrar la conexión con la base de datos para forzar un Commit) me tienes que decir qué tecnología de acceso a datos estás usando. De todas formas creo que es una buena práctica usar dos transacciones (si se puede) o dos conexión con la base de datos: una de sólo lectura para mostrar registros y otra de lectura y escritura para modificarlos.

Espero que sea de ayuda.