Since 1994, regardless of my actual job, I've always found a way to stay involved with Access. I'm certainly no expert but I like working with Access and with the people that work with Access. I just finished attending the MVP Summit in Redmond, my second, and it blows me away at the amount of detail the Access MVPs have of the product and the amount of passion they show in supporting and evangelizing Access. And how willing they are to let us know what they like and don't like about it.

Although not an Access guru, as I said, I just like using it. Don't get me wrong. It's not the perfect application. But with a little investment of time and playful experimentation, it's easy to become comfortable with it's benefits and limitations. And it continues to evolve. The Access product team spends lots and lots of time looking at the feedback they receive from users, MVPs, developers, and aggressively work to implement as much of it as possible. 

One of the comments I hear occasionally that torques me a little is that Access is just a "toy" and that you need SQL Server or Oracle for a "real" database. Tell that to the millions of Access users and developers who make a very comfortable living using and developing complex Access applications. SQL Server is a more robust solution in enterprise applications and is a more secure alternative in situations with hundreds of thousands users. However, Access is ideal in three scenarios: for rapid application development (RAD) where development time and money are an issue; as a front-end to an enterprise database (SQL Server) to put a "friendly" face of the application; and as a data source for interoperating with other Office applications.

In 1995, my first job at Microsoft was as an Access technical support engineer. That was during the days of Access 2.0. I remember how disappointed I was when I had to switch from supporting Access 2.0 to supporting Access 95. I didn't think that 2.0 needed to be improved; obviously pre-XML. 8^D. Anyway, the first two things I learned as a support engineer, especially important in troubleshooting over the phone, was to simplify the problem to its simplest terms, often wading through layers of seemingly disconnected symptoms, and to find some common ground between what the customer had in front of them and what I had in front of me.
The best way I found to do this was to reproduce, as closely as possible, in a short amount of time, the problem I was trying to solve. And the absolutely best way to accomplish all of these objectives was to use the Northwind Traders sample database that ships with Access. You have it and the customer has it. And it looks the same for both of you. If the customer was having a problem with a query, possibly with getting a criteria to work, I could attempt to reproduce the problem with a similar query, run it against "clean" data (the Employees table is my friend), and determine whether the problem was with the query, with the criteria, or with the data. And I could do this without interference from other things that might have been going on with the customer's database.

Using Northwind this way is also a good choice when developing and troubleshooting your own applications. First, the reason that Northwind ships with Access in the first place is to give you a model on which to base your own tables, queries, forms, and reports. In addition, by playing with Northwind (it's a good idea to make a copy to keep from having to reinstall after modifying it), you can learn a lot about relational databases such as relationships, interoperability with other Office applications, table/query/form and report construction techniques, normalization, VBA and data access and manipulation, and so forth. In some situations, you can even copy and paste formulas, forms, reports, code, and even tables (without the data of course) directly from Northwind into you own application with little modification. Additionally, for an existing application, you can try out a new idea in the sterile environment in Northwind before tampering with your own application. And just like the customer support scenario, prototyping in Northwind can be a great way to quickly isolate a problem to its source.

So the next time you need to create a new or customize an existing Access database application, or just want to learn about and play around with database theory or techniques, I'd recommend taking advantage of the RAD capabilities of Northwind.