数据访问的历史 Windows

节选：Programming Microsoft Visual Basic 6.0 1999

The Data Access Saga

All the new database-related capacities in Visual Basic 6 are based on Microsoft ActiveX Data Objects (ADO), a technology that lets you access any database or data source, as long as someone has written an OLE DB provider that connects to that source.

Figure 8-1 summarizes the many ways you can get to a data source in Visual Basic 6. As you can see, data access methods differ greatly in the number of layers that sit between your application and the database you're connecting to. In this book, however, I concentrate on ADO technology and give you only glimpses of the others. Deciding not to cover popular data access techniques such as DAO and RDO has been a difficult choice, but I had to make it to keep this book a reasonable size. I was comforted in this choice by the fact that DAO and RDO haven't been improved at all in Visual Basic 6; so if you already mastered those techniques in Visual Basic 5, there's nothing new for you to see. Both these older technologies will be eventually replaced by ADO. You can find several good books and other information sources about DAO and RDO, such as the superb Hitchhiker's Guide to Visual Basic and SQL Server by William R. Vaughn (Microsoft Press, 1998). Although I don't have the space to describe DAO and RDO in depth, you need at least a broad understanding of how they work. To help you understand the benefits that ADO brings you, I must describe the tools that were available before it and how ADO relates to those older technologies.

Figure 8-1. Accessing a database using ODBC, DAO, RDO, and ADO.

ODBC

ODBC stands for Open Database Connectivity and is a set of functions that lets you connect to a local or remote database. Microsoft launched this technology as a means of accessing several databases in different formats—dBASE, Microsoft FoxPro, Microsoft Access, Microsoft SQL Server, Oracle, or even plain comma-delimited text files—using a common API. The machine the application runs on connects to a DLL called the ODBC Driver Manager, which in turn sends commands to (and retrieves data from) an ODBC driver specific to the particular database you want to use. Visual Basic 2 was the first version of the language that was capable of connecting to an ODBC source. Since then the number of available ODBC drivers has grown very rapidly, to the point that it's nearly impossible to find a commercial database for which no ODBC driver exists.

The challenge of ODBC is to provide a common interface to all these different databases. In theory, you can prepare an application that uses ODBC to talk to an Access database and then upsize to an SQL Server database simply by changing the back-end ODBC driver and a few statements in the source code. You can do this because all the commands you send to the database are standard SQL statements. SQL (Structured Query Language) is a programming language specialized for working with databases. (See "Crash Course in SQL" later in this chapter for an introduction to SQL). In practice, however, while the ODBC layer does what it can to convert these standard SQL commands into the particular database's dialect, an ODBC programmer frequently has to bypass the ODBC translation engine and send commands directly to the database. (These are known as pass-through queries or commands.) Needless to say, having to do this hinders the portability of such an application to another database.

ODBC is efficient, at least compared with most other data access techniques. Another advantage of ODBC is that it supports both 16-bit and 32-bit APIs, so it's one of the few techniques available to Visual Basic 3 and Visual Basic 4/16 applications. ODBC version 3 has added several performance-boosting techniques, such as connection pooling, which means that an ODBC driver on the client side can reuse existing connections in a way that's transparent to your program. For example, your code can open and close multiple connections to a database, but the ODBC driver actually uses the same connection. Because opening a connection is a lengthy operation—it can take several seconds each time—connection pooling is bound to make your application much more responsive. Microsoft Transaction Server uses connection pooling to improve the performance of connections opened by ActiveX components that run under it.

Using ODBC, however, isn't easy, especially for Visual Basic programmers. The set of API functions is complex, and if you make a mistake you often crash your application with a fatal error. (If this occurs while you're in the IDE, you can't even save your code.) For this reason, relatively few Visual Basic programmers write applications that directly call ODBC functions. Interestingly, most other data access techniques available to Visual Basic can use ODBC drivers as intermediate layers, so sometimes you can augment other techniques (typically those based on RDO) with direct API calls. Unfortunately, you can't do that with ADO: Even though ADO internally uses an ODBC driver, you can't mix ADO code and ODBC API code for the same connection.

Even if you're not going to directly use ODBC API calls in your Visual Basic programs, you should become familiar with the basic concepts on which this technology is based. For example, one concept that you'll probably deal with even when working with ADO is the Data Source Name (DSN). A DSN is a set of values that an application needs to correctly connect to a database. It typically includes the name of the ODBC driver you want to use, the name of the machine that hosts the database server (if you're working with client-server engines such as SQL Server or Oracle), the name or path of the specific database, the timeout of the connection (that is, the number of seconds after which the ODBC driver gives up and returns an error to the calling application when trying to establish the connection), the name of the calling workstation and application, and so on.

You can create a DSN in several ways, inside or outside the Visual Basic 6 environment. The command center for ODBC is a Control Panel applet that lets you create DSNs and set other ODBC configuration values. You can choose from several types of DSNs. A User DSN is stored in the system Registry, can be used only by the current user, and can't therefore be shared with others. A System DSN is also stored in the Registry but is visible to all other users, including Microsoft Windows NT services. Finally, a File DSN is stored in a .dsn file and can be shared by all users (provided that the correct ODBC driver is installed on their machines). File DSNs can be easily copied on other machines, so they make the installation phase easier; on the other hand, the application needs to know where the DSN is located, so the code must provide the complete path to the .dsn file, and you need to store the path somewhere (in an INI file, for example). This is never an issue with User or System DSNs.

You aren't forced to work with DSNs if you don't want to. When you're working with ODBC, you can provide all the information needed for the connection—driver name, database name and path, and so on—right in your code. These are the so-called DSN-less connections, which are usually more efficient because you save the ODBC driver a trip to the Registry or to a File DSN. But DSN-less techniques require a bit more work from the developer.

The first three tabs of the ODBC Control Panel applet dialog box let you create, delete, and configure DSNs of all types. As you can see in Figure 8-2, creating a DSN often requires that you open several nested dialog boxes. The Drivers tab displays all the installed ODBC drivers and lets you compare version numbers (which is sometimes important when something doesn't work as expected on a customer's machine). Visual Basic 6 comes with several ODBC drivers (some of which are visible in Figure 8-3), but you can also purchase other drivers from third-party vendors.

You use the Tracing tab of the ODBC Data Source Administrator applet to define the path of the log file for all ODBC operations, which is a lifesaver when you're debugging ODBC-based applications. (This option is vital also when you are indirectly using ODBC through DAO, RDO, or ADO.) The latest version of the ODBC Data Source Administrator applet includes the ability to start Microsoft Visual Studio Analyzer, a tool that lets you monitor the activity of your programs over the network.

In the Connection Pooling tab, you can enable or disable connection pooling for each specific ODBC driver. You rarely need to change these settings, though, and I suggest that you not play with them unless you're pretty sure about what you're doing. Finally, in the About tab, you can check the position and versions of all the code DLLs of the ODBC subsystem.

Figure 8-2. Creating a User DSN for a Microsoft Jet database. The contents of nested dialog boxes depend on the ODBC driver you're connecting to.

Figure 8-3. Some of the ODBC drivers that can be installed by the Visual Basic 6 setup procedure.

DAO

DAO, or Data Access Objects, has a place in the heart of all programmers who began to develop database applications with Visual Basic 3. DAO is an object-oriented interface to Microsoft Jet, the engine that powers Access. Developers can design an MDB database using Access and then use DAO from a Visual Basic application to open the database, add and retrieve records, and manage transactions. The best thing about DAO is that it doesn't limit you to Jet databases because you can directly open any database for which an ODBC driver exists. Or you can use Jet attached tables, which are virtual tables that appear to belong to an MDB database but actually retrieve and store data in other ODBC sources.

Even if you can use DAO to access non-Jet sources, you can clearly see that it was devised with Access databases in mind. For example, even if your application doesn't use MDB databases, you still have to load the entire Jet engine DLL in memory. (And you also have to distribute it to your users). Even worse, DAO doesn't expose many of the capabilities that you could use if working directly with ODBC API functions. For example, you can't perform asynchronous queries or connections using DAO, nor can you work with multiple result sets.

Visual Basic 3 also contained the first release of the Data control. This control lets you bind one or more controls on a form to a data source and offers buttons for navigating through the records of the database table you've connected to. At first, it seems that the Data control is a great tool because it lets you quickly create effective user interfaces to work with your data. After some testing, however, developers tend to abandon the Data control because its many limitations are difficult to overcome. Apart from performance considerations, the Data control has one serious disadvantage: It ties your front-end applications to the data in the back-end database. If you later want to access data in another database, you have to revise all the forms in your application. If you want to add complex validation rules to database fields, you must add code in every single module of the program. These (and other problems) are the typical defects of a 2-tier architecture, which in fact is being abandoned in favor of 3-tier (or n-tier) architectures, where one or more intermediate layers between the application and the database provide services such as data validation, business rules, workload balance, and security. Alas, if you want to embrace the n-tier philosophy, you should forget about the Data control.

Visual Basic 4 included the improved DAO 3.0 version, which features a special DLL that allows programmers who work with 32-bit technology to access 16-bit databases. Visual Basic 5 programmers can use DAO 3.5. In the Visual Basic 6 package, you'll find DAO 3.51, which is substantially similar to the previous one. This suggests that Microsoft doesn't plan to improve DAO further, even though version 4 has been announced for Microsoft Office 2000.

RDO

RDO, or Remote Data Objects, is the first attempt by Microsoft to combine the simplicity of DAO with the power of direct ODBC API programming. RDO is an object model vaguely patterned after DAO, but it bypasses the Jet Engine and the DAO DLL and works directly with the underlying ODBC drivers. Applications based on RDO load only a small DLL instead of the resource-hungry Jet engine. Even more important, RDO was specifically designed to work with ODBC sources, so it exposed functionality that couldn't be accessed from DAO. RDO is 32-bit technology, however, so you can't use it from 16-bit applications.

RDO 1 was introduced with Visual Basic 4, and the engine was improved in Visual Basic 5, which includes RDO 2. This latest version is a mature product and also supports a new programming model based on events, which is great for working with asynchronous operations. The development of RDO seems to have stopped, though, because Visual Basic 6 still includes version 2, with no apparent improvement over the version shipped with Visual Basic 5. So RDO could be another dead end. Although Microsoft seems committed to actively supporting RDO, it seems to be betting everything on ADO.

RDO 1 and 2 came with the RemoteData control, which works in much the same way as the Data control and lets you bind controls to remote data sources. In this sense, the RemoteData control shares all the advantages and disadvantages of the Data control, including its problems with n-tier architectures.

ODBCDirect

Visual Basic 5 included yet another data access technology, named ODBCDirect, which allowed programmers to employ RDO using a DAO syntax. ODBCDirect was conceived as a transition technique that would help Visual Basic programmers move their DAO/Jet applications to more powerful client/server architectures. In theory, by changing just a few properties, an existing DAO program that stores data in a Jet database might be converted to a client/server application that connects to any ODBC source. ODBCDirect shouldn't be regarded as a technology of its own. It's more like a trick that you can use to save time in converting applications, and nothing more. Most of the RDO 2 new features—the new event programming model, for example—can't be exploited by ODBCDirect because it has to be code-compatible with DAO. Besides, being based on RDO, ODBCDirect works only with 32-bit applications. For these reasons, unless you have very big and complex DAO/Jet Visual Basic applications to port to another database as quickly as possible, don't waste your time on ODBCDirect.

OLE DB

OLE DB is a low-level data access technology with which Microsoft intends to eventually replace ODBC as the primary means for connecting to databases. The OLE DB counterpart to ODBC drivers are the OLE DB providers, which work as bridges between applications and databases. Although OLE DB is a relatively recent technology, you can find OLE DB providers for most popular databases, and others will be released before long. In spite of their apparent similarities, ODBC and OLE DB technologies are profoundly different. First, OLE DB is based on COM, an architecture that has proven robust enough to move large quantities of data across the network. Second, OLE DB lends itself to the task of connecting any type of data source, not just relational and ISAM (indexed sequential access mode) databases, which are the natural field for ODBC drivers.

OLE DB is part of Microsoft's Universal Data Access (UDA) strategy, which enables you to read and process data where it is, without first converting it and importing it to a more traditional database. Using OLE DB providers, you can process data in e-mail messages, HTML pages, spreadsheet and text documents, and even in more exotic data sources. Visual Basic 6 itself comes with providers for Microsoft Jet, SQL Server, FoxPro, text files, and Oracle databases. You can download other OLE DB providers from the Microsoft Web site, and I've heard of other providers from third-party vendors.

In the transition between the ODBC and the OLE DB worlds, you can use a special OLE DB provider, named MSDASQL—also known by its code name, Kagera—that works as a bridge to any ODBC source. Instead of connecting directly to the database, you can use this special provider to connect to an ODBC driver, which in turn reads and writes data in the database. This additional layer has a performance hit, of course, but you should look at it as a short-term solution to a problem that will disappear when more providers are available.

ADO

ADO is the high-level interface to OLE DB. It fills more or less the same role that RDO does for the ODBC APIs. Like ODBC APIs, OLE DB is a low-level interface that can't be easily (or at all) accessed from high-level languages such as Visual Basic. ADO builds on OLE DB to provide functions that aren't available directly in OLE DB or that would make stringent demands on the coding abilities of a programmer. ADO matches most of RDO's capacities: Both can make asynchronous queries and connections and optimistic batch updates. ADO adds great new features such as file-based and stand-alone Recordsets, hierarchical Recordsets, and more.

The single most important feature of ADO is probably its extensibility. Instead of being a complex and monolithic object hierarchy as DAO and RDO are, ADO consists of fewer objects that can be combined in more ways. New features can be added to ADO in the form of special OLE DB providers, such as the MSDataShape provider, which offers hierarchical Recordset objects to other providers. Microsoft also is making new features available in ADO in the form of separate libraries that link dynamically to the core ADO library. For example, the new ADO 2.1 library includes support for Data Definition Language and security (that is, the creation of new database tables, users, and groups of users), Jet replicas, and multidimensional Recordsets. Because these additions are distinct libraries, you don't have to distribute them with your applications if you don't use them. This contrasts with DAO and RDO, each of which comprises one larger DLL that embeds all the features (and which you have to distribute in its entirety even if you use a small fraction of its potential).

Another nice ADO feature is that you can use it from within HTML pages in a browser such as Internet Explorer or on a server inside an Active Server Page hosted on Internet Information Server. One ADO subsystem, named Remote Data Services, even lets you send a bunch of records to a client browser or activate COM components remotely over the Internet.

The only relevant defect of ADO is that it's a recent technology that hasn't proven its robustness in a large number of real-world applications, as DAO and RDO have. For example, I found a few bugs in ADO 2, even though my experience is that most of these problems were caused by the OLE DB provider, not ADO itself. This distinction is important because you can often fix these bugs by simply updating the provider when a new version is released. In fact, I found that the providers for Microsoft Jet 4.0 and SQL Server 7.0 are noticeably better than the versions for Jet 3.51 and SQL Server 6.5. (The latter are the providers distributed with Visual Basic 6.) I expect that by the time you read this book, most major problems with ADO will be fixed. On the other hand, the only alternative to ADO is to continue to use DAO or RDO, but, as I've explained, these technologies aren't going to be improved significantly in the future.

You can see that choosing the data access technique to use is a complex matter. My suggestion is simple, though: If you're maintaining or updating an existing application based on DAO or RDO (or ODBC APIs, if you're a brave programmer), wait until you see where ADO is going. If you're beginning a new application, give ADO a try, especially if you plan to update and maintain it for several years or if you plan to eventually port it to the Internet.

The good news is that Visual Basic 6 includes several tools and facilities for creating ADO applications quickly and effectively. For this reason, the rest of this book focuses on ADO exclusively.