Me fui una semana de vacaciones y las vacaciones, SON VACACIONES (y lejos del e-correo que tengo un montón para leer).
El colega pregunta como volver atrás cuando se hizo un proceso de cierre (que el soluciona con una restauración de bd).
Esa solución la he aplicado con sistemas monousuario con tablas nativas y es práctico. Un buen usuario puede hacerlo (recopia el directorio de BK que hizo previo al cierre).
Pero esa solución sobre un BD Postgresql, es como usar un cuatri para empujar el carrito del supermercado.
Como se puede hacer si hacer restaura?
Bueno, acá la cuestión es como se ha instrumentado el sistema y el modelo de datos.
Si es un sistema basado en un modelo contable "puro", se crean contraasientos que neutralizan el proceso incorrecto.
Si las operaciones que se incluyen en el cierre tienen bien la fecha y toda la data generada o es calculable y mantiene su fuente, se podría correr un programa que tome las transacciones y las aplique en forma inversa para volver al punto inicial.
Otra forma es trabajar por estados, en mi caso usaba que los distintos pasos los registros que se estaban procesando pasaban de un estado a otro (p.e.).
0 al crearse, 1 primera pasada, 2 primer control, 3 aprobada, 4 impresa, 5 formalizada, 6 cerrada.
Toda transacción que no estuviera en estado 6 podía retrotraerse a cualquiera de los estados previos. Normalmente, si ya estaba formalizada y tener que borrarla, convenía hacer un proceso de ajuste formal corrector.
Pero todo esto es instrumentable solo si el sistema esta planteado para eso.
Por ejemplo. Todos los movimientos de stock tienen que quedar registrados. No puedo hacer una venta e ir modificar el stock en el registro del producto sin haber guardado los datos del cambio en algún otro lado.
El archivo de movimientos en stock (y esto es válido para cualquier cosa con números que se suman o se restan u otro tipo de cálculo) guarda un valor "testigo" para consultas rápidas y no tener que hacer un SUM() algebraico de los movimientos para reconstruir la existencia (o saldo de cta. cte., o moneda en caja, etc.).
Por eso, la solución a no recargar la bd para anular un proceso de datos fallido, dependerá de como está diseñado el sistema.
postgresql permite bk por tabla también, entonces, no tienes que recuperar toda la bd.
También permite otros tipos de bk que te permiten recuperar a un momento dado, entonces, no tienes que pisar todo.
Además, si hiciste los bk 1, 2, 3, 4, y antes del 5 tenes que recuperar, el fulano encargado se equivoca y restaura el 3, todo lo que va entre 3 y 4 se pierde y si no tienes las transacciones bien cargadas, mamadera!!!
Saludos: Miguel, La Pampa (RA)
Larga Vida y Prosperidad
Que la fuerza los acompañe, para salir a delante y no con un chaleco