Database development is outgrowing Access -- and even some longtime Access developers aren't entirely sad about this trend.
Whether by Microsoft design or just the will of the database gods, Access development is waning. Most Access developers are now working with SQL Server or SQL Server Express with.NET-based and Web-based development tools. A few people are still gainfully employed as Access developers, but most of us no longer use Access for serious development work (much to our chagrin). Still, working with a big engine has its perks, and as much as I loved (still love) Access, there are a few things I don't miss.
Even if you're an Access genius, corruption probably cramps your style occasionally. It just comes with the territory. Now, there are ways to avoid corruption, as discussed in 10 Ways To Prevent Access Database Corruption. The reality is that corruption costs you time and sometimes data. Recovering from corruption is never a fun way to spend a day.
2: The naysayers
When used correctly, Access is an efficient and dependable desktop database. For the last 15 years, it's been the bread and butter of many developers. Yet despite the popularity and capabilities of Access, some people ridicule Access and Access developers. I definitely don't miss hearing their trash-talk every time I recommend Access as a quick alternative to one of the big engines.
3: IT bans
Non-programmers build most Access databases, and the results are often inefficient and difficult to debug. As a result, some IT professionals refuse to support Access. I can't blame them for that. Unfortunately, IT often goes a step further and bans Access from the premises, which complicates things for end users. Waiting for IT to produce a non-critical database can take months. Often, the department just hires an independent contractor (how do you think I get most of my work?) instead.
4: Syntax error or access denied
Access is notorious for its ambiguous error messages. It's a frustrating inadequacy, even for those of us who love the "little database that could." The solution is intense error-handling, but not every project warrants that much development time, and sometimes you have to support a database you didn't develop. If you use Access, you have to deal with inadequate error messages.
5: Fixing someone else's bugs
Nobody misses this less than I do, but fixing someone else's bugs isn't exclusive to Access. Most of us don't enjoy fixing someone else's bugs in any application. It's difficult, it's time-consuming, and the person who wrote the bug is seldom (never) around to consult. It's just the nature of Access' end-user accessibility that makes bugs more prevalent and harder to troubleshoot.
6: Access haters
I'm always a bit surprised when a programmer spits out, "I hate Access!" Any explanation I might offer is suspect, I admit, but Access has a way of working its way into large-scale applications -- places where Access probably doesn't belong. After all, Access is an end-user product, not a development tool. It ruffles feathers more than a little. It's my best guess, but I'm still puzzled by it.
7: Missing references
Missing references cause common functions to stop working and the error messages are no help. You either know what's wrong, someone tells you, or your hair turns gray. It's an easy problem to solve and fortunately, it disappeared from later versions. Most of us are still supporting applications as far back as Access 9,7 though, so we still deal with it.
8: Broken promises
I wish I had a few bucks for every time I've received a call from the owner of an Access database that's not finished and the original developer is no longer available. Sometimes, the developer worked in house and moved on before completing the project. More often than not, the developer promised more than he or she could deliver and quietly disappeared. Trying to pick up where someone else left off is close to impossible. I seldom take on these projects and it's uncomfortable. You want to help these people, but you usually can't. They've already spent a lot of money and they have little to show for it. Trying to help just makes you a target.
9: Missing documentation
Because non-programmers build so many Access databases, there's usually little or no documentation. Seriously, most users wouldn't know what to document anyway because they use wizards to generate everything. That takes us to #10.
10: Wizard-generated code
Access wizards are ingenious; they're innovative and helpful tools. On the down side, they generate horribly inefficient code. Sometimes, wizard code can help you pinpoint an elusive object or property, but I don't actually use it. If I have to enhance wizard-generated code, I (usually) comment it out and start over. Supporting an application that's mostly wizard-generated code is tiresome.