YOU'RE NOT READING THIS BOOK FOR the jokes—at least, I hope not. I hope you're reading it for suggestions on how to write efficient ADO data access applications and how to write them efficiently. This first chapter walks you through some of the fundamentals—the stuff you must have in place to use ADO at all. I'll assume you know what you're doing in most respects, so I'll leave out some of the basic step-by-step stuff you'll find in the "Idiots" books. If you don't know what ADO is, what its object model looks like, or how the objects relate to one another, see the "ADO Fundamentals" appendix at the back of the book.
One of the challenges we all face is determining which version of ADO is the "right" version. Because there are so many versions and because they can work very differently, we often struggle with which version we should use. In some cases we don't have a choice—we have to use what the customer has installed or insists on using. When we do have a choice, we also have to worry about future versions changing (breaking) the software we've deployed. To better understand the myriad of choices, let's take a brief trip through ADO's history.
Since Visual Basic 6.0 shipped in the summer of '98, ADO has transmogrified several times—and yes, into some bizarre forms. Visual Basic 6.0 shipped with an early version of ADO 2.0, and then ADO changed when SQL Server 7.0 shipped, when Internet Explorer 5.0 shipped, and when Office 2000 shipped, and it was updated at least twice thereafter. While some of these changes were minor, some were not, and Visual Basic (Visual Studio) has not kept up very well.
Before ADO 2.0, there was the Microsoft ActiveX Recordset Library (ADOR). Initially, ADOR was intended to serve as a "lightweight" version of ADO—not requiring the complete install, and thus supporting a smaller footprint, less RAM, and faster download times. It turned out to be more trouble than it was worth so with ADO 2.0, the two libraries became one. As a result, setting your reference to the ADOR library is pointless.
Microsoft distributes ADO in the Microsoft Data Access Components (MDAC) package, a 6.35MB executable (mdac_typ.exe) that includes ADO, ODBC, and OLE DB drivers and providers. Yes, Microsoft bundles them all together in a take-one-get-them-all (whether you want them all or not) package. Packaging and installing all of these individual pieces together makes sense for maintaining stability.
The various MDAC pieces, but not necessarily all of them, are installed by many, many applications—applications from both Microsoft and third parties. If you're lucky, these applications "install" MDAC instead of just copying the files over and hoping for the best, as some applications seem to do. I'll show you how to install MDAC a little later in this chapter.
While MDAC moved to its "golden" or "general release" (126.96.36.19902.3 (GA)) in the fall of '99, the Visual Basic SP3, the Visual Studio 6.0 Plus Pack, and the Windows 2000 Readiness Kit did not contain this release. The Visual Basic team tells me that Visual Basic 6.0 SP4, due out in the spring of 2000, should upgrade Visual Basic 6.0 to address issues raised by the interface and functionality changes in ADO 2.1.
I "lurk" on a number of public and internal list servers (such as <VBDATAL@peach.ease.lsoft.com>) where I see a number of questions about ADO. One frequently asked question is, "When one installs Internet Explorer 5.0, does it install ADO 2.1?" The answer is "sort of." That is, Internet Explorer 5.0 installs and uses ADO 2.1, but it does not install the providers and drivers that are installed with the full MDAC setup. So really, installing Internet Explorer 5.0 won't really (completely) install ADO—you will have to distribute and install the MDAC setup with your ADO 2.x client program.
Now that ADO 2.5 has arrived, it's an integral part of Windows 2000, although it can still be installed separately on older versions of Windows by downloading it from the Web at http://microsoft.com/data. (Incidentally, this site is the best place to find out about the most recent version of ADO and MDAC.) This incorporation of ADO in Windows is supposed to mean that ADO will no longer change with every phase of the moon—it'll be harder for everyone to change ADO, even when they have to. It looks like everyone will have to upgrade/patch ADO through OS upgrades. This also means that the big players at Microsoft (Microsoft Office, Internet Explorer, Visual Studio, and others) will not be able to change MDAC willy-nilly (that's a technical term)—and that's good news.
Do not try to use the Office 2000 Installer to remove ADO. This is a fatal mistake that will force you to reinstall Windows 2000.
The real problem with all of these changes is fundamental. When developing a COM component, you as a developer agree to conform to a recognized standard implementation regimen. One of the requirements is that future versions of the component will support all past versions (at least going back a couple of versions). This means that while the code for implementing these published interfaces might change, the interface names, properties, methods, events, and all of the arguments passed to them do not change.
ADO 2.1 broke the rules. ADO 2.0 applications crashed or misbehaved after their customers installed Internet Explorer 5.0 or one of the Office 2000 applications that upgraded ADO from 2.0 to 2.1. What's worse is that ADO kept changing over the months that followed. Even if the interfaces didn't change, MDAC did. In some cases, ODBC driver "improvements" changed security restrictions—locking out users that were previously able to access their databases using default behaviors. Even though ADO 2.1 and 2.5 both include ADO 2.0 typelibs that permit older applications to see their old familiar interfaces, when some of the revised ("improved") event handlers passed back an ADO 2.1 (or 2.5) Recordset instead of the ADO 2.0 Recordset, the applications broke. Some of the most serious "breakages" were in Visual Basic itself. None of the Visual Database Tools would work correctly with ADO 2.1 or later. This meant the Data Environment Designer was crippled. In addition, the ActiveX Data Control, the Data Form Wizard, and the Data Object Wizard were all dented.
At this writing, it's not clear what Microsoft and the MDAC team expect to do about this. They certainly can't revert to the old version. I have tried to get the Visual Studio team to upgrade Visual Basic 6.0 to fully support ADO 2.5, but it remains to be seen whether this will come to pass. Perhaps Visual Studio 6.0 SP4 will address these issues. I'm told that this will all be finally addressed when Visual Basic 7.0 arrives. I'll be long since retired by then…