Fixing a corrupt file

[Christine Pearc]

I was working on a module and query in my Front End on our internal network when suddenly the system crashed. I now get a message saying the file is corrupt. The system is currently stuck with Record Locking on the file. I can't run "Tools, Compact and Repair". I've tried making a copy of the Front End, but the corruption and record locking comes with it.

Our MIS department has a backup from last Friday. Should I delete the file AND record locking, then have MIS reinstall the backup? What about the backend, should we delete that as well? Are there any dangers?

If someone can advise ASAP, I'll be ever so grateful!!

Christine

 

[Uncle Gizmo]

I wouldn't delete anything just yet , why not isolate the damaged files for the time being.

As two sorting out your problem, have you looked in the folder where you're *.mdb is and looked for a file named *.ldb with the same name as the offending access database , if you have this *.ldb file , then move it from the folder to somewhere safe and try again.

 

[Christine Pearc]

Thanks for that, Uncle Gizmo.

You suggested to "isolate the damaged files". Well, the entire database (*.ldb) is damaged as far as I know, and there is no way to isolate the tables, queries, forms, etc. that make it up.

I tried moving the *.ldb files (there were 2: one for the back-end and one for the front-end). However, they continued to remain listed in Explorer. I then swallowed hard and deleted them. I'm still getting the message for ...detected corrpution in this file..."

I can't even get the file to open to use the Compact and Repair tools, so it looks like I'll have to store it from a backup. Darn annoying.

Christine

 

[Uncle Gizmo]

The next thing you could try is to create a new empty database and import all the objects from the crashed database.

 

[Uncle Gizmo]

with regard to the file named *.ldb, this is a file you won't usually see, as it is created when you open your access database and it keeps a list of all the users of the database. When the access database is closed normally this file is deleted. However if your application is terminated unexpectedly then sometimes this file can be left behind and cause problems.

I used to tell people to delete this file, but it occurred to me that although very unlikely, this file extension may apply to some other utility, and instructing people to delete it could leave me liable for causing unnecessary damage. As it is not necessary to delete it, I now, always, suggest people move it to a new directory. I would suggest that anyone else advising people follow a similar policy in this increasingly litigious society.

 

[Christine Pearc]

Sounded like an excellent idea, Uncle, and I gave it a go. Unfortunately, as soon as I specified the mde as the source of my import, its tells me it's corrupted.
Thanks for trying to help me with this. Thank goodness for backups!

Christine

 

[ducker]

just some ideas for future issues. Sometimes it's a particular object that is corrupted and you're unable to modify/delete/move it. A solution that I've found to work is to recreate the database. Create a fresh,new database; import as many objects as possible from the old database, and the one(s) that were corrupted, restore from your backup. That way you won't lose nearly as much work/data as you might of.

-Mike

 

[Christine Pearc]

Thanks, Mike. If this ever happens again, I'll try your suggestion. In this particular case, it didn't work - the whole thing went south. It suspect that the cause was when I was trying to create a new module for a query. I really didn't know what I was doing, trying different things, when it shut down. I tried re-creating the module (in a new database this time!), and the same thing happened, so it must be something in my code it doesn't like. Methinks I'll post to ask for help in the query forum!

Cheers,
Christine