This month’s issue includes one of our “A Day in the Life” articles detailing what it’s like to earn a living working with Access. In that article, Michael Kaplan talks about a variety of topics, including the benefits of specialization (which was a topic in last month’s editorial). Michael also reviews the problems that can arise when working with a client that you disagree with (a topic that, coincidentally, was also discussed in the round table in last month’s issue of Information Systems Consultant). What makes Michael’s article especially interesting is that his client was Microsoft and the disagreement was with the direction that Access 2000 was taking.
I occasionally get asked if developers should upgrade to Access 2000. I always respond with a resounding “Yes, developers should upgrade to Access 2000!” However, the next question, “Should I be upgrading my clients to Access 2000?” is more difficult to answer. The easiest answer to give is the one that applies to all upgrades: “If you need some specific feature that the product provides, you should upgrade. Otherwise, you should always stick with your current toolset.” This answer ducks some important issues, though.
Access 2.0 was a terrific developmental tool. If you were an Access 1.x user, the features that Access 2.0 provided were so compelling that almost any application that you were building would have benefited from the upgrade. Access 95 was a different matter, though. While some of the features were compelling, (such as replication), there was another compelling “feature” that kept developers away from the tool: Access 95 didn’t actually work—at least, not reliably. Among the problems this created for developers was a lack of tools. Great developers need great tools, and the various companies that produce Access developer tools simply couldn’t get Access 95 to be stable enough to create tools to work with the product.
Then there was Access 97. Access 97 added the feature that Access 95 was missing: reliability. Not surprisingly, Access 97 came to dominate the Access development market, eventually pushing out Access 2.0. That’s not to say that, in its time, that Access 95 didn’t have a role to play. Access 95 provided a technology preview for where the Access team was taking our development tool. Looking back, that was really the role that Access 1.x provided: A look ahead at what Access 2.0 was going to be.
I’m afraid that, after living with Access 2000 since its release (and talking to end users, tool makers, and developers), Access 2000 is fulfilling the same role: A technology preview for the next version of Access.
That’s not to compare Access 2000 to Access 95. The product is more reliable than Access 95 was. Though the tool vendors are having their fair share of problems converting their products to Access 2000, the products are starting to appear. My personal feeling is that Access 2000’s ADP products herald the arrival of Access as a true, rapid-application development tool for client/server applications. I still don’t think that Access will ever be an i*net development tool, but Access 2000 makes me willing to believe that it can be part of the solution. As Michael points out in his article, if you’re considering creating an international application, Access 2000 might be your best development platform. Most importantly, Access 2000 points the way to integrating a powerful data access technology—ADO—into a wonderful development platform. I’m learning a lot from Access 2000 and am excited about the possibilities.
Service Release 1 (SR-1), just out as I write this, also fixes some of the problems with Access 2000. In this accompanying Download file, you’ll find Hardin Brothers’ report on SR-1. Hardin lists all of the fixes included in SR-1, along with all of the Knowledge Base articles about problems with Access 2000. Where the service release listed a Knowledge Base article, Hardin matched up the fix with the article. As a result, Hardin’s report links the fixes that have a Knowledge Base article number with the original problem report. More importantly, Hardin also lists all Knowledge Base bug reports for which no corresponding fix seems to exist.
Independently of Access 2000, the new Jet 4.0 database engine still has a role to play. To quote Stephen Forte, “Sometimes, I just want to mail a database,” and Jet lets you do that. Only with Jet can you link multiple databases in a single query (and to the SQL Server users who say that their database engine can, let me point out that it’s only because SQL Server 7.0 ships with a version of Jet). Jet’s ability to create a local database on the fly from code is a feature that I’ve taken advantage of in several applications. The Jet 4.0 engine also eliminates the scalability problems that prevented Jet from being used in i*net applications.
Nonetheless, Access 2000 has some significant stability problems, and its new file format makes it very difficult to have multiple developers working on a single large project. Does this mean that Smart Access won’t be covering Access 2000? No—in fact, this editorial introduces an issue with two articles on Access 2000. We’ll continue you to give you in-depth coverage on the important new features of the latest version of Access. You might find in these articles the feature that compels you to upgrade, or, having already upgraded, you might find a solution to a specific problem that you’re facing. While Access 2000 won’t be the focus of our coverage, we intend to remain your best source for information on ADO and all versions of Access.
But I’m having my clients stick with Access 97, for now.