Page 1 of 1

Recovering a DB with a corrupted map file without reloading

Posted: Fri Aug 07, 2009 1:24 pm
by ConvertFromOldNGs
by cnwrjp1 >> Tue, 2 Dec 2008 22:21:32 GMT

Hi all,

I have a test system that was running on a machine that failed, and after the file system was reconstructed, it left one of my map files corrupted. Is there anyway of getting the system back up in whatever state I can have it in without restoring the map file from a backup (which I don't have in this case - Yes, I know I should have made one).

I am not particularly cared about the data in the map file itself as is is only test stuff, but I am interested in trying to get back some schema changes that were made in this system.

I tried using jdbutil to delete the problematic map file, but jdbutil will not perform any such operations while the DB requires recovery.

Any ideas?

Thanks
Roland

Re: Recovering a DB with a corrupted map file without reloading

Posted: Fri Aug 07, 2009 1:24 pm
by ConvertFromOldNGs
by Allistar >> Tue, 2 Dec 2008 23:03:39 GMT

If you just want to get to the metadata, you could take a blank Jade system that is at the exact same version and then copy in all of the _user*.dat file to it and then do a "reset timestamps". That should allow you to log into the Jade IDE.
--
A.

Re: Recovering a DB with a corrupted map file without reloading

Posted: Fri Aug 07, 2009 1:24 pm
by ConvertFromOldNGs
by Dean Cooper >> Wed, 3 Dec 2008 0:54:59 GMT

That would have worked in an earlier release, but I suspect it won't now because the "dirty" flag will be set in the _user*.dat files in your current system. This flag didn't exist in earlier releases. When you copy these files into the fresh JADE environment, I think you might still get an error when the database tries to open them. Please post a reply if it works though...

Dean.

Re: Recovering a DB with a corrupted map file without reloading

Posted: Fri Aug 07, 2009 1:24 pm
by ConvertFromOldNGs
by cnwrjp1 >> Wed, 3 Dec 2008 2:03:30 GMT

Thanks Allistar for your suggestion. I had already tried this and as Dean suggested, it failed due to the _user*.dat files requiring recovery also.
I guess I will just reload my saved .scm and .ddb files into a new system and rollback my brain's journal to priory to the extract :-)

R.