One of the benefits of hanging around in this business is that I get to meet a lot of people who are brighter than me and far more knowledgeable. Unfortunately, they keep upsetting my vision of the Access universe. For instance, a recent upsetting incident is about to cause me to issue a heartfelt apology to you.

I was presenting at a conference recently when Andy Baron, one of the most intelligent and capable people I know (and who has forgotten more about Access than I could hope to know), commented that the best way of working with SQL Server from Access was to use linked tables. My whole life flashed before my eyes.

When Access Data Projects first appeared they seemed, at best, a good idea. While they provided a deeper integration between Access and SQL Server, there were several significant limitations (the inability to link tables to an Access Data Projects – ADP project comes to mind). However, the major problem for me was that working with ADPs was just so very different from working with Jet databases that it hardly seemed like Access at all. Here at Smart Access, we didn’t give a lot of attention to ADPs.

However, the second iteration of ADPs seemed to address these issues. Most importantly to me, a combination of the right version of SQL Server and the right version of Access made the ADP development process look very much like the standard Access development process. Mea culpa: I assumed that this progress would continue, allowing my favorite tool for creating data-driven applications (Access) to work effectively with the features of a great server database (SQL Server). It’s not that I have anything against Jet, but Jet has some significant limitations (the most critical being the lack of a transaction log to support full recovery after a system failure). There were also many things to like about SQL Server—creating stored procedures leaps to mind, even if you did have to write them in that most peculiar of languages, T-SQL. It seemed to me that ADPs were going to provide the hardcore Access developer with an access point to the features of a great server database.

That’s not going to happen in the near future. The next version of SQL Server is a very different product from the current version of SQL Server. As a result (and this was explained to me by Mary Chipman, yet another very smart person), it becomes very difficult to maintain a deep integration between the current version of Access and the next version of SQL Server. Furthermore, because the release schedules for Access and SQL Server are so different, it will be difficult to synchronize the two products in the immediate future.

But then Russell Sinclair comes along, and he’s been doing most of his work with ADPs. It turns out that ADPs are exactly the right solution for the projects that he’s working on. Where all the tables are kept in a SQL database, Russell has found that ADPs provide a high efficiency way of taking advantage of the power of SQL Server. In his article in this month’s issue, he points out what he likes best about SQL Server development (stored procedures) and how he’s bridged the gap between ADPs and Access.

What can I say? It’s a big, complicated world out there.
So, I’m sorry: I led you astray. ADPs aren’t the solution for every problem. You’re going to have to look at your problem, look at the potential solutions, and decide what works best for you.

My next encounter was more pleasant and led to one of the articles in this month’s issue. When Garry Robinson suggested an article on using Access Help, I thought that the man was mad. I’d be the first person to admit that it’s not his fault: Garry lives in Australia. I assume, since I’m right side up, that all Australians are upside down and the result must be an excessive accumulation of blood in the head. You might, for the same reason, expect me to have too much blood in my feet, except that I spend so much time sitting down.

But then Garry showed me the number of complaints about the Access Help system in the feedback we got about what you’d like to see in the next version of Access. I also realized how much of my time I spend looking outside of Access for Help that, ideally, should be in Access Help. So, in this month’s issue, we have Garry’s article on how to get the most help with Access.

Speaking of Garry in Australia, it made me think about just how global my business friends are. While I sit up here in Canada, Smart Access is published in the United States and distributed all over the world. Most of my consulting clients are in the U.S. also. While Russell is up here in Canada with me, I’m nearing the end of writing a book for Wrox on ASP.NET custom controls and Web Parts (very cool technology) aided and abetted by an editor (Sara Shlaer) and a technical editor (Richard Puchas) both of whom are also in Australia with Garry. You can’t have too many friends, I always say. We won’t comment on how far they seem to stay away from me.