Buenos días

En mi propia experiencia lo de los campos de fecha y hora sólos producen múltiples conflictos porque la sincronización horaria es algo complejo y de difícil control.

Si se tratan de transacciones una solución sencilla es generar un ID único por registro (incluyendo un ID único del equipo). A la hora de consolidar en el servidor únicamente hay que chequear que el ID único exista o no para agregar o no la transacción y tiene la ventaja que si ese ID es consecutivo se pueden detectar fácilmente transacciones faltantes.

Si se tratan de actualizaciones, por ejemplo datos de un archivo de clientes, yo utilizo además del campo de fecha y hora (que la mayor parte de las veces no sirve para nada) un campo lógico de modificación que se coloca en verdadero cuando se modifica y se coloca en falso cuando se actualiza el servidor. Este modelo se complica mucho cuando se trata de actualizaciones de más de una vía (cliente A a servidor, servidor a cliente A, cliente N...)

Para las actualizaciones un modelo que me ha funcionado bien en general es el siguiente: cuando se actualiza un archivo (por ejemplo el archivo de clientes) en la misma transacción de actualización del archivo maestro grabo un archivo de transacciones de actualizaciones. Es decir, actualizo el archivo de clientes y grabo simultáneamente un archivo secuencial donde queda el campo y el dato actualizado (como si fuera una tabla LOG). Luego en el servidor se corren esas actualizaciones secuencialmente en el mismo orden en que se grabaron. Este modelo tiene el inconveniente de que las transacciones de actualización hay que limpiarlas (zap) cuando se actualizan en el servidor y eso normalmente exige una confirmación manual del usuario, que como todos sabemos siempre elegirá la opción equivocada en el momento equivocado.

Espero que te sirvan estos comentarios.

Saludos cordiales

Manuel Tovar
Barranquilla - COLOMBIA