Read an Excerpt
Chapter 1: Working with ADO
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.Choosing the "Right" Version of ADO
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 VisualBasic (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-oneget-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" (2.1.2.4202.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 wont really (completely) install ADO-you will have to distribute and install the MDAC setup with your ADO 2.x client program.
ADO 2.5 Arrives
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.
WARNING Do not try to case the c, face 2000 Installer to remove ADO. This isa fatal mistake that will farce you to reinstall Windows2000.
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)...