Many people deploy Microsoft Access database applications and neglect to provide the system administration necessary to properly support and maintain them over time. This becomes critical as the data it contains grows and becomes mission critical. Often, when something goes wrong, IT "professionals" are brought in to discover basic system administration are not in place. Rather than blaming the people involved, the Microsoft Access technology is considered at fault. We can do better.
Here's a repsonse I recently provided related to this issue:
First, I hope you have a disaster recovery plan in place. You may want to read my paper for what we consider best practices:Creating a Backup and Disaster Recovery Plan for Microsoft Access Database Applications.
Second, Access/Jet databases need to be periodically compacted to minimize corruption and bloat, and for optimal performance. The back-end database with the data is what needs to be compacted. You can do that manually. We created a commercial program Total Visual Agent: that does it on a schedule with auditing and email notification if something goes wrong.
Third, if you are experiencing corruption after regular database maintenance, it's often caused by a suspect connection/user who disconnects in an improper manner. That can be very difficult to detect and replicate. We have a commercial product, Total Access Admin, that monitors the people going in and out of an Access database, logs that activity, and flags the people that exit improperly. If it's happening with the same person, there may be a hardware or network problem causing the corruption.
Finally, it may be possible that the corruption and performance problems are due to the front-end application. Bad code and techniques, corrupt objects, and other issues may be causing crashes and problems that lead to corruption. We address this in a few ways:
1. We adopt, implement, and detect/fix deviations recommended by Total Access Analyzer: Microsoft Access Best Practices Techniques
2. We implement global error handling that records crashes by users to text files so we have evidence of what failed. In addition to the procedure call stack, current procedure, error number and description, we also want the line number: http://www.fmsinc.com/free/NewTips/VBA/ErrorHandling/LineNumber.html This makes it significantly easier and quicker to reproduce and fix bugs.
Overall, it's about having a solid and repeatable process and checklist in place that evolves over time as new experiences are encountered.
Luke
