It's important to understand that any time an Access client disconnects unexpectedly, it may set a "corruption flag" in the .mdb file indicating that the database is in a corrupt state (regardless of whether any data has actually been corrupted or not). Any user who attempts to open the database while this flag is set will receive a message, and the database will have to be repaired before it can be used. If the users don't have permission to perform the repair, or don't know how to perform the repair, there may be significant downtime before the database is available again. This can result in a loss of productivity as well as extreme frustration for the users. Following the 5 tips below will minimize your odds of data loss from corruption in your Access databases.



1) Split your database.

The single most important thing you can do to prevent corruption in MS Access databases is to split the database into a "front-end" and a "back-end". The front-end contains all of the forms, queries, and reports, while the back-end contains only the data tables. A copy of the front-end is placed on each user's computer, and the back-end with the table data is stored in a shared folder on the network. How does this prevent corruption? Well, consider the amount of information that must make it across your network to your computer each time you open a form or report. If one bit of that information doesn't make it intact, you risk corrupting your database. Alternatively, if the forms, queries and reports are all stored on your local computer, then the only bit of information that needs to traverse the network is the actual table data. By reducing the amount of data you need to move back and forth across the network, you significantly reduce the chances of corrupting your database. If you're having corruption problems with an Access database on a network drive, splitting the database is the single most important thing you can do to stop it.

2) Don't hold connections open.

This one applies to both programmers and users. If you're a programmer, make sure you close your connections as soon as possible after using them. Leaving the connections open will allow more opportunities for an "unexpected" dropped connection. The only time you may want to leave a connection open longer than required would when it's used inside a loop. For such a case, open the connection at the beginning of the loop, and then close it after the loop is completed. Just make sure it gets closed for all cases (including exceptions).

If you're using a Microsoft Access database or application, be sure to close it when you're finished. Again, leaving the application open provides the opportunity for corruption if a network connection is lost. Remind users to always close the application before going home, as nightly backup jobs may fail or cause corruption in the shared file if there are open connections.

3) Exit the database correctly.

Always close the database or application correctly. Ctrl-Alt-Delete/End Task can wreak havoc on Access databases. Whenever possible, complete your tasks, then close the application using the File - Exit menu option or alternative Exit option provided by the application.

4) Don't skimp on hardware.

Remember that the corruption flag can be set from the slightest packet loss between your computer and the database file. MS Access has sometimes been called "the canary in the coal mine". It has gained this reputation from being the first application to "die" when there's the slightest hint of trouble on your network. Just like the slightest presence of gas caused the canary to die, the slightest presence of network problems and packet loss can kill your Access applications. Make sure you're not using the cheap built-in NICs that come with some PCs. Instead, use brand name network cards. The same goes for cheap hubs. Whenever possible, match good brands of equipment throughout your network.

5) Compact and repair regularly.

Performing the built-in compact and repair function regularly is recommended to prevent corruption and improve performance. Consider automating this function with a utility to compact and repair all of your databases nightly or during the weekend.

Error messages to look out for - the following error messages may signal database corruption:

"The database 'databasename.mdb' needs to be repaired or isn't a Microsoft Access database file."

"Record(s) can't be read, no read permissions on 'databasename.mdb'"

"Unexpected Error 35012"

"Unrecognized database format ?databasename.mdb'."

"?databasename.mdb' isn't an index in this table. Look in the Indexes collection of the TableDef object to determine the valid index names."

"The Microsoft Jet database engine could not find the object 'databases'. Make sure the object exists and that you spell its name and path name correctly."

"The database has been placed in a state by user '' on machine '' that prevents it from being opened or locked"

"Disk Error -- Reserved error (-1601)"

"The database has been placed in an unexpected state."

"Record(s) cannot be read no read permission on 'MSysObjects'"

"Record(s) cannot be read no read permission on 'MSysACEs'."

"The Microsoft Jet database engine cannot find the input table or query 'MSysAccessObjects'. Make sure it exists and that its name is spelled correctly."

Conclusion:

While you may never be able to prevent all Microsoft Access database corruption, you should be able to stop 98% of the problems before they occur by following these 5 simple tips. Follow these tips and implement a prudent automated backup schedule to minimize your odds of significant data loss.

Kevin Sparks is a technical writer for Kaizen Software Solutions, the producer of Digital DBA, an automated MS Access monitoring, backup, and compact/repair utility. For more information, visit their website at