If possible, consider write-protecting a shared front end. This decision really has no impact on corruption, so the choice is yours. There is some discussion about whether the front end should be stored on a network server (and shared) or on a local drive. In addition, this setup makes enhancements easier to incorporate into your system. With the data and interface objects in separate databases, you can easily replace the front end from a backup, if necessary. Remember, the backend contains your 'gold' - your data. Access has a wizard that holds your hand through the process so there's no excuse not to split a shared database. If more than one person will access the database, split it into two pieces: a backend that stores the data in tables and a front end that contains everything else (forms and reports). Note: This information is also available as a PDF download. Here are some strategies for preventing your databases from becoming corrupted. (Or rather, your replacement will rebuild and re-enter it.)Ī more proactive approach to the situation is to avoid corruption in the first place. But you could end up rebuilding and re-entering data. Sometimes, a third-party product that specializes in recovering data from a corrupted database can help.
With a little know-how, you might get lucky enough to repair the database or at least recover the data.
Nothing frustrates the full spectrum of Access users - from casual user to developer - quite like a corrupted database.
