Recuperar borrados

[Huasi]

Hola que tal, alguien sabe si existe la manera de recuperar registros borrados como lo podía hacer en los .dbf de DOS que me permitían restaurar registros eliminados o borrarlos definitivamente (algo así como la papelera de reciclaje). Resulta que no me convence dejar marcas que señalen un borrado ni tampoco una query sofisticada para regenerar un borrado accidental, por lo que de existir esta opción en SQL 2008 estaría bueno saber como usarla, saludos...

[Libras]

podrias usar transacciones, por ejemplo un

Código SQL:

BEGIN tran
DELETE FROM tabla
 

verificas los datos borrados

Código SQL:

SELECT * FROM tabla
 

si te convencen los borrados ejecutas

Código SQL:

commit tran
 

si no te convences con un

rollback tran :)


puedes configurar sql server para que cada transaccion necesite un commit :)

[Huasi]

Hey Libras como va, vos sabes que utilizo transacciones para todo lo q sea ABM pero la pregunta no va por ese lado, me explico mejor. Resulta que tengo un sistema web con una base de datos para multiples clientes. Si alguno de mis clientes borra un registro de una tabla importante se puede desencadenar un proceso en cascada que puede borrar cientos de otros registros. Si la base de datos únicamente le perteneciera a este cliente la restauro y listo, pero al ser utilizada por varios clientes mas mis opciones son:

1. En lugar de borrar el archivo dejo una bandera en algún campo que se utilice para esto y reformulo todos los where en los select que llamen a esa tabla o,

2. Armo una Query para ejecutarla sobre la base restaurada para que lea e reinserte todo lo que mi cliente borro accidentalmente

Yo no se si SQL borra definitivamente o no los registros cuando ejecuto una query Delete, en el caso que no lo haga me interesaría saber donde esta esa información y como recuperarla. Con los .dbf en la época de DOS se podía hacer, por eso me parece raro que esto no se pueda realizar ahora.

[Libras]

se guarda en los archivos del log de transacciones como recuperarla, llevando un bkp de los registros de transacciones, lo mas conveniente en este caso es que lo lleves con un campo Active/Inactive, es mas seguro que eliminar registros y mas facil de analizar que de regresar un query "gigantezco"

[Huasi]

Recuperar a traves del log de transacciones acarrea el problema de que me trae de vuelta toda la base de datos cuando yo solo necesito recuperar una porción. Por otro lado, lo malo que tiene el campo Active/Inactive (yo le llamo bandera :P) es que no borra nada y de esa manera se me dispara el crecimiento de la base, pero bueno supongo que con una política de mantenimiento para el borrado de los inactive luego de un determinado tiempo eso no seria problema. Gracias por la ayuda, saludos

[Malenko]

Iniciado por Huasi

Recuperar a traves del log de transacciones acarrea el problema de que me trae de vuelta toda la base de datos cuando yo solo necesito recuperar una porción. Por otro lado, lo malo que tiene el campo Active/Inactive (yo le llamo bandera :P) es que no borra nada y de esa manera se me dispara el crecimiento de la base, pero bueno supongo que con una política de mantenimiento para el borrado de los inactive luego de un determinado tiempo eso no seria problema. Gracias por la ayuda, saludos

Te comento mi experiencia. Yo ofrezco a los clientes campañas de marketing donde pueden subir sus agendas, gestionarlas, crear campañas, etc. Entre las operaciones con las agendas y las campañas también está la de "borrar".

Lo que yo hago no es borrar los datos porque luego es imposible saber que ha pasado (sí, se puede tirar del log de transacciones pero es muy pesado). En lugar de hacer un "Delete" prefiero usar un campo "bandera" para indicar si el registro esta borrado/inactivo. En mi caso, lo que hago es poner un campo que puede ser NULL y que llamo "fechaBaja". El hacerlo que sea un campo de tipo DateTime tiene el proposito adicional de saber en que fecha se realizó la baja.

Con esto tenemos un sistema en el que las bajas (o borrados) pueden ser reversibles por el administrador. Para solventar el tamaño del crecimiento lo que usamos es una segunda tabla de historicos. Con un job que se ejecuta cada día una vez, se pasan los registros cuya fecha de baja sea superior a 1 mes (por ejemplo). En mi caso tengo la obligación de tener que guardar todos los registros históricos pero en tu caso al cabo de "x meses" o "x dias" puedes hacerles el delete definitivo si no los necesitas.

[Huasi]

Gracias por contestar, ahora tengo las cosas un poco mas claras. Seguramente voy a optar por tu recomendación, en mi caso si la información que borra el usuario, si lo hace intencionalmente puedo generar problema si no le respeto su decisión y le hago una marca, por lo que lo de la segunda tabla me parece una buena opción, saludos...

Huasi