Recuperar datos de un BD dañada
En la empresa para la que trabajo se utiliza en red una aplicación desarrollada por mí con Microsoft Access 97 para gestionar las citas. El lunes pasado, debido a un corte de suministro eléctrico, se dañó el fichero .mdb que contiene los datos de las citas. Al intentar ejecutar el comando 'Reparar' se obtiene un mensaje que informa que el fichero no es una base de datos Access. Lo he intentado desde la línea de comandos con la opción '/repair', creando un procedimiento en otra base de datos de nueva creación, etc. Por fin, desesperado, he probado a acceder a los datos de diversas maneras:
- Cambiando la extensión por .xls y abriendo la BD desde Excel. Se pueden ver algunos datos, pero el fichero no se carga entero.
- Importando en una nueva base de datos el archivo, con punteros .xls o .txt. Pero carga un solo registro.
- Cambiando la extensión por .txt y abriéndolo con NotePad. Se pueden ver los datos, pero no identifico los nuevos registros introducidos desde el último back-up.
Existe un back-up del día anterior realizado justo después de reparar y compactar la base de datos. Los datos a recuperar están en dos tablas en las que, por motivos de auditoría, se registran el usuario y la fecha/hora en la que se modificó el registro.
El problema es que el campo fecha/hora tiene un formato 'fecha larga' de Access que no se visualiza como dd/mm/aaa hh:nn:ss al abrir el fichero dañado con NotePad, además, al variar la hora de registro, tampoco puedo identificar campos iguales, aún a pesar de haber localizado la ubicación de la mayor parte de los datos de las tablas con registros a recuperar. Ambas tablas tienen como clave principal un campo autonumérico, que tampoco se visualiza en un formato legible en el archivo dañado, que podría haber servido para identificar los nuevos registros introducidos después del back-up.
Otro problema añadido es el volumen de datos, que en una de las tablas es de más de 30.000 registros, muchos de ellos registrados por el mismo usuario que registró los perdidos ayer por la mañana, por lo que el usuario tampoco sirve como identificación.
El tamaño del back-up de la base de datos es de 22 Mb. El del fichero dañado 42 Mb.
Como puede verse, tengo un bonito problema.
¿Puedes hacerme alguna sugerencia, en primer lugar para recuperar los datos, y en segundo para prevenir estos desastres?.
Quedaré eternamente agradecido a quién conteste.
- Cambiando la extensión por .xls y abriendo la BD desde Excel. Se pueden ver algunos datos, pero el fichero no se carga entero.
- Importando en una nueva base de datos el archivo, con punteros .xls o .txt. Pero carga un solo registro.
- Cambiando la extensión por .txt y abriéndolo con NotePad. Se pueden ver los datos, pero no identifico los nuevos registros introducidos desde el último back-up.
Existe un back-up del día anterior realizado justo después de reparar y compactar la base de datos. Los datos a recuperar están en dos tablas en las que, por motivos de auditoría, se registran el usuario y la fecha/hora en la que se modificó el registro.
El problema es que el campo fecha/hora tiene un formato 'fecha larga' de Access que no se visualiza como dd/mm/aaa hh:nn:ss al abrir el fichero dañado con NotePad, además, al variar la hora de registro, tampoco puedo identificar campos iguales, aún a pesar de haber localizado la ubicación de la mayor parte de los datos de las tablas con registros a recuperar. Ambas tablas tienen como clave principal un campo autonumérico, que tampoco se visualiza en un formato legible en el archivo dañado, que podría haber servido para identificar los nuevos registros introducidos después del back-up.
Otro problema añadido es el volumen de datos, que en una de las tablas es de más de 30.000 registros, muchos de ellos registrados por el mismo usuario que registró los perdidos ayer por la mañana, por lo que el usuario tampoco sirve como identificación.
El tamaño del back-up de la base de datos es de 22 Mb. El del fichero dañado 42 Mb.
Como puede verse, tengo un bonito problema.
¿Puedes hacerme alguna sugerencia, en primer lugar para recuperar los datos, y en segundo para prevenir estos desastres?.
Quedaré eternamente agradecido a quién conteste.
1 Respuesta
Respuesta de asturcon3
1
Joer, que putadón...
Bueno, al grano. Primero con lo simple. Microsoft proporciona una herramienta un tanto más potente que el reparador integrado en access. Se llama JetComp y te la puedes bajar de
http://support.microsoft.com/default.aspx?scid=kb;en-us;273956
Si hay suerte, felicidades. Si no, pues vamos a ver. Mencionas casi todo lo que se me ocurre para recuperar información, pero te falta crear una base de datos en blanco e intentar importar las tablas de la dañada. Curiosamente, a veces funciona.
ELSE
El formato de fecha de Access es un número en coma flotante (con decimales) del que la parte entera indica los días transcurridos desde el 30/12/1899. Es decir, cdate(0)=esa fecha, cdate(1)=31/12/1899, cdate(2)=1/1/1900, etc.
Por más señas, ejecutando en el depurador
? cdbl(cdate("3/10/2003"))
Te devuelve 37897. Haz lo mismo con la fecha de los registros que buscas y podrás saber qué numerito buscar.
En cuanto a la parte fraccionaria, indica la porción de día transcurrido. Es decir, el numerito + 0.5 indica las 12 del mediodía. No creo que te sirva de nada.
En todo caso, con el notepad no lo vas a ver, porque se vuelve loco al intentar interpretar los códigos de control ASCII, y además los números se almacenan en un formato binario (creo, esto no estoy seguro) por lo que necesitarías un editor hexadecimal y algo de ojo clínico, que no parece que tengas (aunque llevas hecho mucho para lo que se suele ver por aquí). Si te animas,
prueba con el Ultraedit. Búscalo en Google.
En todo caso, si la base de datos se compactó en la última copia de seguridad, tienes todos los registros antiguos en los primeros 22MB. Te los puedes saltar si buscas los nuevos.
A partir de ahí, tienes que tener en cuenta que Access almacena los datos en bloques de 2KB, por lo que todo registro nuevo que se introduce, o cabe en el mismo pedazo de 2k que el registro anterior o salta directamente al siguiente. Bloques consecutivos pueden ser de la misma tabla, si en una tabla se inserta más que en la otra, o alternos, de una tabla y luego de otra.
Ufff, lo tienes claro. Ah, existe una herramienta de recuperación de Access que a veces, si hay chiripa, consigue algo, pero tienes que registrarte y pagar. Mira mensajes antiguos en este foro y acabarás por encontrarla, yo no me acuerdo del nombre.
Y en cuanto a prevención, lo primero es que no te puedes fiar de Access. Yo lo que tengo en mi PC es una tarea programada cada CUARTO DE HORA de 9 a 21 horas que corre un fichero .bat que dice
del sisber.mdb
xcopy ..\sisber.mdb . /M
if not exist sisber.mdb goto nocopia
del tmp.mdb
ren sisber.mdb tmp.mdb
if exist copia50.mdb del copia50.mdb
if exist copia49.mdb ren copia49.mdb copia50.mdb
if exist copia48.mdb ren copia48.mdb copia49.mdb
if exist copia47.mdb ren copia47.mdb copia48.mdb
...
if exist copia02.mdb ren copia02.mdb copia03.mdb
if exist copia01.mdb ren copia01.mdb copia02.mdb
"C:\Archivos de programa\JetCompact\jetcomp" -src:tmp.mdb -dest:copia01.mdb
del tmp.mdb
:Nocopia
Es muy cutre pero funciona. Borra el fichero temporal, copia del original con el atributo /M, que indica que el fichero ha sido modificado, y si en verdad lo ha sido y se produce la copia, entonces remunera 50 copias anteriores que mantengo a un número posterior, borrando la última y reemplazando la primera por el resultado de ejecutar el JETCOMP directamente.
Resultado. Cada cuarto de hora, sólo si estoy utilizando la base de datos, se produce una copia compactada. Por la hora del fichero sé cuál es cuál. Si el mdb estaba abierto en el momento de la copia, posiblemente tenga algún dato corrupto, pero posiblemente no. Si tengo un casque en el mdb principal, tiro de la primera copia, si está mal voy a la segunda. Nunca he tenido que pas
Bueno, al grano. Primero con lo simple. Microsoft proporciona una herramienta un tanto más potente que el reparador integrado en access. Se llama JetComp y te la puedes bajar de
http://support.microsoft.com/default.aspx?scid=kb;en-us;273956
Si hay suerte, felicidades. Si no, pues vamos a ver. Mencionas casi todo lo que se me ocurre para recuperar información, pero te falta crear una base de datos en blanco e intentar importar las tablas de la dañada. Curiosamente, a veces funciona.
ELSE
El formato de fecha de Access es un número en coma flotante (con decimales) del que la parte entera indica los días transcurridos desde el 30/12/1899. Es decir, cdate(0)=esa fecha, cdate(1)=31/12/1899, cdate(2)=1/1/1900, etc.
Por más señas, ejecutando en el depurador
? cdbl(cdate("3/10/2003"))
Te devuelve 37897. Haz lo mismo con la fecha de los registros que buscas y podrás saber qué numerito buscar.
En cuanto a la parte fraccionaria, indica la porción de día transcurrido. Es decir, el numerito + 0.5 indica las 12 del mediodía. No creo que te sirva de nada.
En todo caso, con el notepad no lo vas a ver, porque se vuelve loco al intentar interpretar los códigos de control ASCII, y además los números se almacenan en un formato binario (creo, esto no estoy seguro) por lo que necesitarías un editor hexadecimal y algo de ojo clínico, que no parece que tengas (aunque llevas hecho mucho para lo que se suele ver por aquí). Si te animas,
prueba con el Ultraedit. Búscalo en Google.
En todo caso, si la base de datos se compactó en la última copia de seguridad, tienes todos los registros antiguos en los primeros 22MB. Te los puedes saltar si buscas los nuevos.
A partir de ahí, tienes que tener en cuenta que Access almacena los datos en bloques de 2KB, por lo que todo registro nuevo que se introduce, o cabe en el mismo pedazo de 2k que el registro anterior o salta directamente al siguiente. Bloques consecutivos pueden ser de la misma tabla, si en una tabla se inserta más que en la otra, o alternos, de una tabla y luego de otra.
Ufff, lo tienes claro. Ah, existe una herramienta de recuperación de Access que a veces, si hay chiripa, consigue algo, pero tienes que registrarte y pagar. Mira mensajes antiguos en este foro y acabarás por encontrarla, yo no me acuerdo del nombre.
Y en cuanto a prevención, lo primero es que no te puedes fiar de Access. Yo lo que tengo en mi PC es una tarea programada cada CUARTO DE HORA de 9 a 21 horas que corre un fichero .bat que dice
del sisber.mdb
xcopy ..\sisber.mdb . /M
if not exist sisber.mdb goto nocopia
del tmp.mdb
ren sisber.mdb tmp.mdb
if exist copia50.mdb del copia50.mdb
if exist copia49.mdb ren copia49.mdb copia50.mdb
if exist copia48.mdb ren copia48.mdb copia49.mdb
if exist copia47.mdb ren copia47.mdb copia48.mdb
...
if exist copia02.mdb ren copia02.mdb copia03.mdb
if exist copia01.mdb ren copia01.mdb copia02.mdb
"C:\Archivos de programa\JetCompact\jetcomp" -src:tmp.mdb -dest:copia01.mdb
del tmp.mdb
:Nocopia
Es muy cutre pero funciona. Borra el fichero temporal, copia del original con el atributo /M, que indica que el fichero ha sido modificado, y si en verdad lo ha sido y se produce la copia, entonces remunera 50 copias anteriores que mantengo a un número posterior, borrando la última y reemplazando la primera por el resultado de ejecutar el JETCOMP directamente.
Resultado. Cada cuarto de hora, sólo si estoy utilizando la base de datos, se produce una copia compactada. Por la hora del fichero sé cuál es cuál. Si el mdb estaba abierto en el momento de la copia, posiblemente tenga algún dato corrupto, pero posiblemente no. Si tengo un casque en el mdb principal, tiro de la primera copia, si está mal voy a la segunda. Nunca he tenido que pas
Muchísimas gracias por tu atención. La respuesta me parece muy completa. Otra cosa será que pueda recuperar los datos antes de que todas las citas estén sobrepasadas.
Sólo comentarte que algunas de tus sugerencias ya las había llevado a cabo:
- He creado una base de datos en blanco y he intentado importar las tablas de la dañada. Sin éxito.
- He intentado abrir el fichero con otros editores para leerlo en hexadecimal, pero las herramientas con las que lo he intentado no pueden con el fichero. La táctica fue otro fracaso.
- Y algunas otras 'trampitas' aún más negras.
En fin, tu aportación me ha abierto nuevas vías. Aunque, te comentaré los resultados obtenidos hasta el momento.
Ya he probado la primera, ejecutando JetComp. Tampoco tiene éxito.
Con UltraEdit-32 se puede abrir el archivo, y así he podido comprobar la magnitud del desastre. He identificado los nuevos registros insertados, pero sus datos parecen mezclados, de modo que se visualiza parte del nombre de un cliente mezclada con parte del de otro, a veces con referencia a la fecha y hora de la cita, y a veces sin ella, etc. No te aburro con lo que se puede visualizar.
Si mi empresa lo paga, probaré los otros métodos, pero visto lo visto, auguro poco éxito.
En cuanto al procedimiento preventivo, implementaré algo parecido, pero tengo que estudiar la forma en la que la recuperación no dependa de mí directamente y en cómo minimizar el espacio ocupado por las copias.
De nuevo, muchas gracias.
Sólo comentarte que algunas de tus sugerencias ya las había llevado a cabo:
- He creado una base de datos en blanco y he intentado importar las tablas de la dañada. Sin éxito.
- He intentado abrir el fichero con otros editores para leerlo en hexadecimal, pero las herramientas con las que lo he intentado no pueden con el fichero. La táctica fue otro fracaso.
- Y algunas otras 'trampitas' aún más negras.
En fin, tu aportación me ha abierto nuevas vías. Aunque, te comentaré los resultados obtenidos hasta el momento.
Ya he probado la primera, ejecutando JetComp. Tampoco tiene éxito.
Con UltraEdit-32 se puede abrir el archivo, y así he podido comprobar la magnitud del desastre. He identificado los nuevos registros insertados, pero sus datos parecen mezclados, de modo que se visualiza parte del nombre de un cliente mezclada con parte del de otro, a veces con referencia a la fecha y hora de la cita, y a veces sin ella, etc. No te aburro con lo que se puede visualizar.
Si mi empresa lo paga, probaré los otros métodos, pero visto lo visto, auguro poco éxito.
En cuanto al procedimiento preventivo, implementaré algo parecido, pero tengo que estudiar la forma en la que la recuperación no dependa de mí directamente y en cómo minimizar el espacio ocupado por las copias.
De nuevo, muchas gracias.
http://www.lencom.com/desc/indexN1338.html
Bueno, y si piensas que tu trabajo puede costar más de 50 euros, puedes probar con
http://www.access-repair.com/
http://www.accessdatabaserepair.com/
http://www.datarevive.com/
Bueno, y si piensas que tu trabajo puede costar más de 50 euros, puedes probar con
http://www.access-repair.com/
http://www.accessdatabaserepair.com/
http://www.datarevive.com/
