If you're still able to open the problematic database, it makes an awful lot of sense to grab what you can, while you can..

Frist, Make a screenshot of the Startup Menu screen. To easiest way to do this is to select Tools > Startup from the menu.

You'll see a screen somewhat like the example shown above. Take a screen shot (Alt + PrtSc) and paste it into a Word document (don't forget to save the document!) The reason the information on this screen is useful is because it shows any special settings in your current database that you want to be sure to set up in the new database.

Capture special settings created in the Options menu as well (available from Tools > Options). Make screen shots of any screens that show selections different from the default settings; since it's not easy to detect these differences, this is a case when its better to have too much information rather than not enough.

In a like manner, if you have written any code for your application, you'll want to capture any references you've made. From the code window (control-g will get you there), go to Tools > References. From the menu that pops up make a screenshot of any references that you've set in your applications (see example below).

Now completely close out of your old application and start a brand-new application. Be sure not to use a template or any starter file that you might use for new applications. In this case, it's important that you start with a brand-new, unadulterated file.

From the tables tab (or the tables object list if you're using 2003) select New Table. You'll get the screen below.

From this list choose Import Table. You'll have an opportunity to browse to a file; browse to the database file that is giving you trouble.

You'll see the screen below where you can select the components you wish to import:

Click on each of the tabs and choose Select All and move on to the next tab. After you've selected all on each tab, click OK.

At this point Access will import each of the objects from your old database file into your new database file. During this process, you'll often discover that one of the objects will not import properly and you'll get an error message letting you know that that particular object is corrupt beyond recovery. You'll have to manually rebuild that particular item; however, you'll have rescued all of the other objects in your database and now have a solid starting point for recovering your application.

As a last step, utilize the screen shots you made earlier to check the selections you'd made in your former database on the Startup, Options, and References settings.

At this point you'll have a new file which you can use as a starting point for moving forward from your "corrupt beyond repair" file. Of course, you'll want to give this new database a distinctive name to mark it as new. This rebuilding process is not something that you would do casually, but it can rescue you from a very difficult and painful situation.

The past two months I've been talking about problems with corrupt databases. I've already mentioned that Network Interface Cards are a frequent source of the problem; however, there are some instances where user behavior is the cause. The primary example of this is not properly closing a database. If you shut off your computer using the power button (and not the recommended process of shutting down your computer through the Start menu) while a database is open, you could damage that database.

Also, damage can be caused when more than one user accesses the same record at the same time. In theory, Access handles the situation without a problem. However, in practice there are times where this behavior damages the database. I'll talk about this in more detail in the future. In the meantime, if you suspect you're in a situation where multiple users access the same database at the same time, you want to read up on record locking to avoid damaging the file.