Okay, one last time: Access isn’t going away. I justread another article from another pundit who, having noticed that a version ofSQL Server is going to be included in the enterprise version of Access 2000,proclaimed that this means the end of Access. Let’s get it right: Access isn’ta database system. Access is a tool for creating database applications (and oneof the best on the market). In order to make Access useful right out of thebox, Access ships with an ISAM, desktop database system called Jet (also one ofthe best on the market). However, Access can be used to create front ends forany kind of database, including Excel spreadsheets, as Garry Robinsondemonstrated in last month’s issue (see “Adding Database Tools to ExcelSpreadsheets”).
Nor does the eventual dominance of ADO mean that Access isgoing away. ADO isn’t a database, and it isn’t a tool for creatingapplications. ADO is a means for accessing data in any format from anyapplication development tool. And, from what I’ve seen, the best tool on themarket for working with ADO is going to be Access 2000.
However, Access is going to change, and there might come atime when it’s very difficult to point to one thing and say, “That’sAccess.” The villain here (if there is one) is COM and Microsoft’s driveto componentize everything. If you convert to Access 2000, one of the firstthings you’ll notice is that the code development environment that we’ve grownto love/hate is gone. What you’ll find, instead, is a separate application thatallows you to create Basic modules, Class modules, and all the other componentsof VBA. If you want to see what this environment looks like, start Word orExcel or PowerPoint and press Alt-F11 to start its VBA editor. There you go.The VBA engine and editor is just one more component that Microsoft can put ina package with other Microsoft products and sell.
Microsoft’s component strategy shows up most when you look atthe References list for any of its development tools. What you see is a list ofobjects, some of which are automatically checked off when you start Access (orWord or Excel or . . .). The box on the Egghead (virtual) shelf that’s labeled”Visual Basic” contains the same VBA engine as Access. But it alsoincludes some special runtime objects, some data access objects (RDO), astandalone editor, and a compiler. Presumably, any of these objects could berepackaged with any of Microsoft’s other development tools. What Microsoft hasdone is create an inventory of tools and objects that can be put together inany combination for which marketing can identify a buyer.
One of the latest additions to this inventory is Visual DataTools (VDT). Like the VBA editor, this is a standalone component that shipswith a variety of products (Visual InterDev 1.0 and 6.0, and Visual Basic 6.0,among others). VDT works with a variety of database backends to create queries,design tables, and manipulate the data in those tables. Hmmm, sounds likeAccess’s various data design tools. It’s not hard to imagine, then, that Access’sspecialized data design tools could be replaced by the snap-in functionality ofVDT.
So what’s left? Well, there’s Access’s report writer. Butthen, Visual Basic just got a banded report writer. Well, then what aboutAccess’s Form object, which contains more data-related events than theequivalent VB form object? Well, what about it? Why couldn’t Access and VBshare an enhanced Form object that had all the features of both tools?Microsoft has announced a Form+ project already.
In the end, Access might turn into a marketing product thatdescribes a particular set of objects and tools in a box labeled”Microsoft Access.” If it does come to this, the question will be howsuccessfully Microsoft can deliver a tool with the productivity and ease of useof version we have come to love (and hate).
Erratum: I managed to do the unthinkable last issue and, inediting my Access Answers column, I edited some errors into the article. Thelast paragraph in the second answer in the column should have read:
The Column property accepts as a parameter the column of theentry in the listbox whose value you want to retrieve. The Column property thenreturns the value for the current row in the listbox (you can determine thecurrent row by using the listbox’s ListIndex property). Since you know that theGuestId is in column 1, the code becomes:
dbs.Execute("Insert Into tblAssignments Values(" & _ lstGuests.Column(0) & ", " & frmTable.TableId & ");")
Fortunately, I didn’t go back and correct the sampledatabase, which contains the correct code.