ODBC was created in the late '80s and early '90s to provide a uniform interface for writing client software for relational databases. ODBC provides a single API for client applications to work with different databases. Applications that use the ODBC API can communicate with any relational database for which there is an ODBC driver. Compared to other database interfaces, the ODBC API could be classified as a low-level database interface. The ODBC API enables client applications to configure and control the database at a relatively low level. Figure 10.3 illustrates the architecture of ODBC. Figure 10.3 : The ODBC architecture. ODBC was designed to provide an interface to relational databases. ODBC has become quite popular and is generally accepted as a standard for interfacing with relational database systems. ODBC is limited to relational databases. Because of the relational nature of ODBC, it's difficult to use ODBC to communicate with non-relational data sources, such as object databases, network directory services, email stores, and so on. ODBC provides the ODBC Driver Manager (ODBC32.DLL), an import library (ODBC32.LIB), and ODBC header files for the ODBC API. Client applications link with the import library to use the functions exposed by the ODBC Driver Manager. At runtime, the ODBC Driver Manager calls functions in the ODBC drivers (which are also DLLs) to perform operations on the databases, as shown in Figure 10.3. ODBC does not provide an embedded SQL interface. With embedded SQL, the SQL code is embedded in the application program source code. A precompiler transforms the SQL code at build time into native function calls that call the database's runtime library. ODBC provides a call-level interface (CLI). A CLI is a special kind of database API. A CLI, like a typical API, provides functions for client applications to call. However, in a CLI, the SQL code in the client application is not precompiled. Rather, the API provides functions that enable the application to send the SQL code to the database at runtime. The SQL code is interpreted at runtime. ODBC is a nontrivial topic. You will explore the architecture of ODBC (and write some ODBC code) in Day 14, "Legacy Database APIs."
MFC ODBC Classes
ODBC was created to provide a uniform interface to relational databases. However, the ODBC API isn't necessarily simple. In Visual C++, MFC provides classes that simplify the ODBC API. The MFC ODBC classes make ODBC programming much less complex. You used the MFC ODBC classes in Day 1, "Choosing the Right Database Technology," in Listing 1.4. The MFC ODBC classes are easier to use than the ODBC API but do not give you the low-level control that the ODBC API offers. Therefore, the MFC ODBC classes could be classified as a high-level database interface. You will learn more about using the MFC ODBC classes in Day 15, "The ODBC API and the MFC ODBC Classes."
DAO
DAO stands for Data Access Objects. Data Access Objects is a set of (COM) Automation interfaces for the Microsoft Access/Jet database engine. DAO talks directly to Access/Jet databases. DAO can also communicate with other databases through the Jet engine, as shown in Figure 10.4. The COM-based Automation interface of DAO provides more than a function-based API. DAO provides an object model for database programming. The DAO object model is better suited to object-oriented development than a straight API. Integrating a set of disparate API functions into an object-oriented application typically means that the developer must write her own set of classes to encapsulate the API functions. Figure 10.4 : DAO architecture. Rather than provide merely a bunch of functions, DAO provides a set of objects for connecting to a database and performing operations on the data. These DAO objects are easy to integrate into the source code of an object-oriented application. In addition to including classes for connecting to a database and manipulating data, the DAO object model also encapsulates the structural pieces of an Access database, such as tables, queries, indexes, and so on. This means that DAO also enables you to directly modify the structure, or schema, of Access databases without having to use SQL DDL statements. DAO provides a useful object model for database programming, but as you can see from Figure 10.4, several layers of software are involved. Note that if you are using DAO to talk to a database server such as Oracle or SQL Server, all the calls into the database and all the data coming out of the database must pass through the Access/Jet engine. This can be a significant bottleneck for applications that use a database server. DAO is easier to use than the ODBC API but doesn't provide the degree of low-level control afforded by the ODBC API. Therefore, DAO could be classified as a high-level database interface. There is a set of MFC classes that further simplify the DAO Automation interfaces. The MFC DAO classes are prefixed with CDAO. You can find information on these MFC classes in the Visual C++ documentation. On Day 14, you will learn more about DAO and the MFC DAO classes.
RDO
RDO stands for Remote Data Objects. RDO was originally developed as an abstraction of the ODBC API for Visual Basic programmers. Therefore, RDO is closely tied to ODBC and Visual Basic. RDO is easier to use than the ODBC API but doesn't offer the low-level control provided by the ODBC API. Therefore, RDO could be classified as a high-level database interface. Because RDO calls the ODBC API directly (rather than through Jet, like DAO), it can provide good performance for applications that use relational database servers. RDO can be used with Visual C++ applications by inserting the RemoteData control in the application. The RemoteData control is an OLE Control that can be bound to controls in the application's UI. You can call RDO functions through the RemoteData control's methods. You will learn more about RDO in Day 14.
OLE DB
As I mentioned earlier, OLE DB stands for object-linking and embedding database. The OLE DB name makes more sense as an acronym. You will understand why in a moment. OLE DB expands on ODBC in two important ways. First, OLE DB provides an OLE-actually, a COM-interface for database programming. Second, OLE DB provides an interface to both relational and nonrelational data sources. OLE DB provides an OLE (COM) interface. OLE was the original name for COM. When OLE DB was being created, OLE was still used as the name for COM. Since that time, COM has become the name for the foundation of Microsoft's component technology (which you explored yesterday), and OLE has come to be associated with UI components such as OLE Controls (OCX Controls). Used as an acronym, the OLE DB name invokes an image of OLE/COM and databases, which is accurate. However, the expanded object-linking and embedding database name makes no sense. This is why I say the OLE DB name makes more sense as an acronym. I think the technology might best be named COM DB instead of OLE DB because OLE DB has little to do with UI components such as OLE Controls. Unfortunately, Microsoft has yet to seek my approval of the OLE DB name and seems committed to using the OLE DB term. OLE DB's provision of a COM interface for database programming is important because a COM interface can be much more robust and flexible than a traditional call-level interface, such as the ODBC interface. This flexibility can result in better performance and more robust error handling and can enable interfacing with nonrelational data sources. Like ODBC, OLE DB could be classified as a low-level database API. OLE DB incorporates the functionality of ODBC for relational databases and expands on it by providing access to nonrelational data sources. There are two kinds of OLE DB software: OLE DB consumers and OLE DB providers. Figure 10.5 illustrates the relationship between OLE DB consumers and OLE DB providers. Figure 10.5 : OLE DB consumers and providers. An OLE DB consumer is any application that uses or consumes OLE DB interfaces. For example, any application that you write in C++ and that uses OLE DB to connect to a database server would be an OLE DB consumer. OLE DB providers are DLLs that implement the OLE DB interfaces and do the actual communication with the data source. OLE DB providers are similar in function to ODBC drivers, except that OLE DB providers implement COM interfaces instead of API functions. OLE DB furnishes access to any data source for which there is an OLE DB provider. These data sources include email stores, object databases, network directories, and other nonrelational data stores. As you can see in Figure 10.5, there is an OLE DB provider called MSDASQL.DLL that can talk to ODBC data sources. This is handy for those data sources that have an ODBC driver but don't yet have an OLE DB provider. OLE DB exposes a set of COM interfaces that can be called from C++ programs. OLE DB doesn't offer an Automation interface. OLE DB is the future of database client development on Windows. Microsoft's own development efforts are focused on OLE DB. It's unlikely that we will not see any further updates of ODBC. ODBC will stick around in its present form, and all the new database client technology from Microsoft will be applied to OLE DB. OLE DB is the focus of Days 16-21.
ADO
ADO stands for ActiveX Data Objects. ADO is built on top of OLE DB. ADO is an OLE DB consumer. Applications that use ADO use the OLE DB interfaces indirectly. ADO provides an object model for database programming that's similar to, but more flexible than, DAO's object model. For instance, you can create Recordset objects in ADO without first creating a Connection object (which is something you can't do in DAO). ADO simplifies OLE DB. OLE DB is large and complex; a program that uses OLE DB must use some complex COM interfaces. ADO is much simpler to use than OLE DB and can be classified as a high-level database interface. Also, ADO can be used with more programming languages than OLE DB. ADO provides an Automation interface. This enables ADO to be used from scripting languages, such as VBScript and JavaScript. (OLE DB can't be used from scripting languages because scripting languages don't have pointers and therefore can't use COM interfaces.) You've already used ADO objects in Days 4, 5, and 6 to connect to a database, issue queries, retrieve resultsets, and execute stored procedures. You will use ADO objects more today.
28.8.1 Microsoft 数据访问简介 这些年，M i c r o s o f t 提出了许多数据访问策略，这些策略大多都以大写首字母的方式来表示，比如 O D B C 、D A O 、R D S 和U D A 。为了帮助我们准确地理解它们，多花些时间了解M i c r o s o f t 数据访问策略 的首字母缩写的含义是很值得的。学习了这些内容后，你会更清楚A D O 的含义。 • UDA(Universal Data Access)是M i c r o s o f t 提供的通用数据访问策略，包括A D O 、OLE DB 和O D B C 。 有趣的是它不光提供了数据库的访问能力，对于其他的数据存储技术也支持，比如目录服务、 E x c e l 的表格数据和E x c h a n g e 服务器数据。 • ODBC(Open Database Connectivity)是目前经确认的最好的数据访问技术。O D B C 结构包含了一 个普通的基于S Q L 的A P I ，它利用对应的驱动程序来开发特定的数据库程序。由于存在巨大的市 场，并且对现在的任何数据库都支持，所以，O D B C 在很长一段时间内还将使用，尽管它已存在 了很长时间。 • RDO(Remote Data Objects)为O D B C 提供了一个C O M 的封装。其目的是简化O D B C 的开发和在 Visual Basic 和V B A 程序中发展O D B C 。 • J e t 是安装在Microsoft Access 中的数据库引擎。J e t 支持Microsoft Access 本身的M D B 数据库和 O D B C 。 • DAO(Data Access Objects)是另一个基于C O M 的数据访问A P I 。D A O 提供了对J e t 和O D B C 的封装。 • O D B C D i r e c t 是M i c r o s o f t 后来为D A O 添加的对O D B C 的直接访问。强于通过J e t 对O D B C 进行支持。 • OLE DB 是一种普通和简化的基于C O M 的数据访问规则和A P I 。OLE DB 被设计成为独立于特殊 的数据库后端和底层结构，并且它是M i c r o s o f t 最新的数据连接方案。驱动程序(称为OLE DB 提 供者)可以通过OLE DB 与任何数据存储建立链接。
ADO---Active Data Objects,活动数据对象
DAO---Data Access Objects,数据访问对象
RDO---Remote Data Objects,远程数据对象
ODBC---Open Database Connectivity,开放式数据库连接性
DSN---Data Source Name,数据源名
BDE---Borland Database Engine,Borland数据库引擎
JET---Joint EngineTechnology,数据连接性引擎技术
OLEDB---Objects Link Embed DataBase对象链接嵌入数据库
ado.odbc.bde
另外我不明白它们的访问关系，谁来解释一下？下面的表示对吗？DAO也一样吗？?
ado-->ODBC-->DB
ado-->OLEDB-->DB
ado-->OLEDB-->ODBC-->DB
期待高手出现!
ODBC was created in the late '80s and early '90s to provide a uniform interface for writing client software for relational databases. ODBC provides a single API for client applications to work with different databases. Applications that use the ODBC API can communicate with any relational database for which there is an ODBC driver. Compared to other database interfaces, the ODBC API could be classified as a low-level database interface. The ODBC API enables client applications to configure and control the database at a relatively low level. Figure 10.3 illustrates the architecture of ODBC. Figure 10.3 : The ODBC architecture. ODBC was designed to provide an interface to relational databases. ODBC has become quite popular and is generally accepted as a standard for interfacing with relational database systems. ODBC is limited to relational databases. Because of the relational nature of ODBC, it's difficult to use ODBC to communicate with non-relational data sources, such as object databases, network directory services, email stores, and so on. ODBC provides the ODBC Driver Manager (ODBC32.DLL), an import library (ODBC32.LIB), and ODBC header files for the ODBC API. Client applications link with the import library to use the functions exposed by the ODBC Driver Manager. At runtime, the ODBC Driver Manager calls functions in the ODBC drivers (which are also DLLs) to perform operations on the databases, as shown in Figure 10.3. ODBC does not provide an embedded SQL interface. With embedded SQL, the SQL code is embedded in the application program source code. A precompiler transforms the SQL code at build time into native function calls that call the database's runtime library. ODBC provides a call-level interface (CLI). A CLI is a special kind of database API. A CLI, like a typical API, provides functions for client applications to call. However, in a CLI, the SQL code in the client application is not precompiled. Rather, the API provides functions that enable the application to send the SQL code to the database at runtime. The SQL code is interpreted at runtime. ODBC is a nontrivial topic. You will explore the architecture of ODBC (and write some ODBC code) in Day 14, "Legacy Database APIs."
MFC ODBC Classes
ODBC was created to provide a uniform interface to relational databases. However, the ODBC API isn't necessarily simple. In Visual C++, MFC provides classes that simplify the ODBC API. The MFC ODBC classes make ODBC programming much less complex. You used the MFC ODBC classes in Day 1, "Choosing the Right Database Technology," in Listing 1.4. The MFC ODBC classes are easier to use than the ODBC API but do not give you the low-level control that the ODBC API offers. Therefore, the MFC ODBC classes could be classified as a high-level database interface. You will learn more about using the MFC ODBC classes in Day 15, "The ODBC API and the MFC ODBC Classes."
DAO
DAO stands for Data Access Objects. Data Access Objects is a set of (COM) Automation interfaces for the Microsoft Access/Jet database engine. DAO talks directly to Access/Jet databases. DAO can also communicate with other databases through the Jet engine, as shown in Figure 10.4. The COM-based Automation interface of DAO provides more than a function-based API. DAO provides an object model for database programming. The DAO object model is better suited to object-oriented development than a straight API. Integrating a set of disparate API functions into an object-oriented application typically means that the developer must write her own set of classes to encapsulate the API functions. Figure 10.4 : DAO architecture. Rather than provide merely a bunch of functions, DAO provides a set of objects for connecting to a database and performing operations on the data. These DAO objects are easy to integrate into the source code of an object-oriented application. In addition to including classes for connecting to a database and manipulating data, the DAO object model also encapsulates the structural pieces of an Access database, such as tables, queries, indexes, and so on. This means that DAO also enables you to directly modify the structure, or schema, of Access databases without having to use SQL DDL statements. DAO provides a useful object model for database programming, but as you can see from Figure 10.4, several layers of software are involved. Note that if you are using DAO to talk to a database server such as Oracle or SQL Server, all the calls into the database and all the data coming out of the database must pass through the Access/Jet engine. This can be a significant bottleneck for applications that use a database server. DAO is easier to use than the ODBC API but doesn't provide the degree of low-level control afforded by the ODBC API. Therefore, DAO could be classified as a high-level database interface. There is a set of MFC classes that further simplify the DAO Automation interfaces. The MFC DAO classes are prefixed with CDAO. You can find information on these MFC classes in the Visual C++ documentation. On Day 14, you will learn more about DAO and the MFC DAO classes.
RDO
RDO stands for Remote Data Objects. RDO was originally developed as an abstraction of the ODBC API for Visual Basic programmers. Therefore, RDO is closely tied to ODBC and Visual Basic. RDO is easier to use than the ODBC API but doesn't offer the low-level control provided by the ODBC API. Therefore, RDO could be classified as a high-level database interface. Because RDO calls the ODBC API directly (rather than through Jet, like DAO), it can provide good performance for applications that use relational database servers. RDO can be used with Visual C++ applications by inserting the RemoteData control in the application. The RemoteData control is an OLE Control that can be bound to controls in the application's UI. You can call RDO functions through the RemoteData control's methods. You will learn more about RDO in Day 14.
OLE DB
As I mentioned earlier, OLE DB stands for object-linking and embedding database. The OLE DB name makes more sense as an acronym. You will understand why in a moment. OLE DB expands on ODBC in two important ways. First, OLE DB provides an OLE-actually, a COM-interface for database programming. Second, OLE DB provides an interface to both relational and nonrelational data sources. OLE DB provides an OLE (COM) interface. OLE was the original name for COM. When OLE DB was being created, OLE was still used as the name for COM. Since that time, COM has become the name for the foundation of Microsoft's component technology (which you explored yesterday), and OLE has come to be associated with UI components such as OLE Controls (OCX Controls). Used as an acronym, the OLE DB name invokes an image of OLE/COM and databases, which is accurate. However, the expanded object-linking and embedding database name makes no sense. This is why I say the OLE DB name makes more sense as an acronym. I think the technology might best be named COM DB instead of OLE DB because OLE DB has little to do with UI components such as OLE Controls. Unfortunately, Microsoft has yet to seek my approval of the OLE DB name and seems committed to using the OLE DB term. OLE DB's provision of a COM interface for database programming is important because a COM interface can be much more robust and flexible than a traditional call-level interface, such as the ODBC interface. This flexibility can result in better performance and more robust error handling and can enable interfacing with nonrelational data sources. Like ODBC, OLE DB could be classified as a low-level database API. OLE DB incorporates the functionality of ODBC for relational databases and expands on it by providing access to nonrelational data sources. There are two kinds of OLE DB software: OLE DB consumers and OLE DB providers. Figure 10.5 illustrates the relationship between OLE DB consumers and OLE DB providers. Figure 10.5 : OLE DB consumers and providers. An OLE DB consumer is any application that uses or consumes OLE DB interfaces. For example, any application that you write in C++ and that uses OLE DB to connect to a database server would be an OLE DB consumer. OLE DB providers are DLLs that implement the OLE DB interfaces and do the actual communication with the data source. OLE DB providers are similar in function to ODBC drivers, except that OLE DB providers implement COM interfaces instead of API functions. OLE DB furnishes access to any data source for which there is an OLE DB provider. These data sources include email stores, object databases, network directories, and other nonrelational data stores. As you can see in Figure 10.5, there is an OLE DB provider called MSDASQL.DLL that can talk to ODBC data sources. This is handy for those data sources that have an ODBC driver but don't yet have an OLE DB provider. OLE DB exposes a set of COM interfaces that can be called from C++ programs. OLE DB doesn't offer an Automation interface. OLE DB is the future of database client development on Windows. Microsoft's own development efforts are focused on OLE DB. It's unlikely that we will not see any further updates of ODBC. ODBC will stick around in its present form, and all the new database client technology from Microsoft will be applied to OLE DB. OLE DB is the focus of Days 16-21.
ADO
ADO stands for ActiveX Data Objects. ADO is built on top of OLE DB. ADO is an OLE DB consumer. Applications that use ADO use the OLE DB interfaces indirectly. ADO provides an object model for database programming that's similar to, but more flexible than, DAO's object model. For instance, you can create Recordset objects in ADO without first creating a Connection object (which is something you can't do in DAO). ADO simplifies OLE DB. OLE DB is large and complex; a program that uses OLE DB must use some complex COM interfaces. ADO is much simpler to use than OLE DB and can be classified as a high-level database interface. Also, ADO can be used with more programming languages than OLE DB. ADO provides an Automation interface. This enables ADO to be used from scripting languages, such as VBScript and JavaScript. (OLE DB can't be used from scripting languages because scripting languages don't have pointers and therefore can't use COM interfaces.) You've already used ADO objects in Days 4, 5, and 6 to connect to a database, issue queries, retrieve resultsets, and execute stored procedures. You will use ADO objects more today.
RDO和DAO微软已经放弃，我就不多说了。但是必须承认，连接SQL Server的时候RDO的效率超过ADO。
ODBC作为一个标准，地位正在受到OLEDB的挑战。OLEDB的可扩展性和与ADO完美的结合使得我们可以访问任意位置的数据，从SQL Server、DB2、informix标准DBMS到EXCEL，outlook通讯簿，AD等等非传统的数据系统，而且OLEDB的SDK可以从MS站点免费下载，使用VC既可开发(VB的数据模块基于OLE Provider，功能上也类似，但是不能算真正的OLE Provider)。但是作为一个跨平台的标准，由于有IBM的支持，在unix品台商ODBC仍然是最大的赢家。
BDE,JDBC没有用过
是真的吗 ?
还好,还好,还没改!!
我用的就是RDO,我还想把它改成ADO呢?其实ADO,不错,挺简单的,因为是COM的产物,又什么地方都可以用.ASP,WORD,VB...
但我现在用的是Interbase,因为是免费用,而且装起来也容易不过我想问一下各位,VC中的ADO是不是有类似ODBC的 Recordset 类??
还是只能使用原生的ADO模型??
ADO 通用的 OLEDB 提供者来工作
JDBC 通用各自己DBMS 提供的 驱动来工作
DBI 通用 DBD 来工作
三个东西都是只提供一个界面， 具体的实现由底层去完成。 如DBI， 通过 DBI->connect("dbi:....:database","user","passwd") 生成 dbh(连接句柄, 通过dbh 可以生成查询句柄(sth), 通过sth 可以处理查询结果.
而ADO则是通过 adodb.connection 建立联接. 用 ADODB.recordset 处理查询.用 ADODB.command 来预处理 SQL.
JDBC更是和 ADO 一样, 连对 DBMS 的提供功能的查询处理都是一样. 说实话, 我更喜欢 DBI 的风格, 简洁明了, ADO 和 JDBC 的联接 URL 实在是不是人写的.
这些年，M i c r o s o f t 提出了许多数据访问策略，这些策略大多都以大写首字母的方式来表示，比如
O D B C 、D A O 、R D S 和U D A 。为了帮助我们准确地理解它们，多花些时间了解M i c r o s o f t 数据访问策略
的首字母缩写的含义是很值得的。学习了这些内容后，你会更清楚A D O 的含义。
• UDA(Universal Data Access)是M i c r o s o f t 提供的通用数据访问策略，包括A D O 、OLE DB 和O D B C 。
有趣的是它不光提供了数据库的访问能力，对于其他的数据存储技术也支持，比如目录服务、
E x c e l 的表格数据和E x c h a n g e 服务器数据。
• ODBC(Open Database Connectivity)是目前经确认的最好的数据访问技术。O D B C 结构包含了一
个普通的基于S Q L 的A P I ，它利用对应的驱动程序来开发特定的数据库程序。由于存在巨大的市
场，并且对现在的任何数据库都支持，所以，O D B C 在很长一段时间内还将使用，尽管它已存在
了很长时间。
• RDO(Remote Data Objects)为O D B C 提供了一个C O M 的封装。其目的是简化O D B C 的开发和在
Visual Basic 和V B A 程序中发展O D B C 。
• J e t 是安装在Microsoft Access 中的数据库引擎。J e t 支持Microsoft Access 本身的M D B 数据库和
O D B C 。
• DAO(Data Access Objects)是另一个基于C O M 的数据访问A P I 。D A O 提供了对J e t 和O D B C 的封装。
• O D B C D i r e c t 是M i c r o s o f t 后来为D A O 添加的对O D B C 的直接访问。强于通过J e t 对O D B C 进行支持。
• OLE DB 是一种普通和简化的基于C O M 的数据访问规则和A P I 。OLE DB 被设计成为独立于特殊
的数据库后端和底层结构，并且它是M i c r o s o f t 最新的数据连接方案。驱动程序(称为OLE DB 提
供者)可以通过OLE DB 与任何数据存储建立链接。
用Visual Basic 访 问 数 据 库 有 许 多 可 供 选 择 的 方 案， 但 是 选 择 那 种 方 案 更 能 使 开 发 队 伍 和 应 用 软 件 在 今 天 处 于 有 利 位 置 并 且 适 应 将 来 的 发 展 方 向 呢 ？ 这 些 解 决 方 案 各 有 什 么 特 点 ？ 本 文 将 说 明 这 些 问 题， 帮 助 使 用VB5 的 用 户 和 准 备 使 用VB5 的 用 户 选 择 和 决 定 哪 种 数 据 库 访 问 方 案 对 现 在 很 有 意 义 而 且 适 应 将 来 的 应 用 程 序。
---- 当 今，RDO2.0 是Visual Basic 访 问 关 系 型ODBC 数 据 源 的 最 佳 界 面 接 口， 就 如DAO/Jet 是Jet 和ISAM（ 顺 序 索 引 查 找 方 法） 类 型 数 据 源 首 选 的 访 问 接 口 一 样。 这 两 种 方 法 都 完 整 的 集 成 于Visual Basic 中， 并 且 形 成 了Visual Basic 核 心 的 数 据 访 问 策 略。RDO2.0 的 数 据 访 问 速 度 远 快 于RDO1.0 的 访 问 速 度， 并 且RDO 和DAO 都 已 发 展 为 相 当 成 熟 的 技 术。 因 此 假 如 用 户 需 要 访 问ODBC 数 据 源， 可 以 使 用RDO； 如 果 需 要 访 问ISAM 或Jet 类 型 数 据 源， 那 么 就 使 用DAO/Jet。 ---- Active Data Objects(ADO) 作 为 另 一 种 可 供 选 择 的 技 术 出 现， 正 在 逐 渐 代 替 其 他 数 据 访 问 接 口。 由 于RDO 同ADO 的 体 系 结 构 非 常 相 似， 因 此 当 需 要 将RDO 数 据 接 口 转 换 为ADO 时， 仍 可 以 使 用RDO 设 计 的 代 码。 ---- 有 人 曾 提 出 这 样 的 问 题： 是 否 现 在 就 使 用ADO? 虽 然VB5 使 用ADO 的 数 据 访 问 接 口 是 可 能 的， 但 对 于 目 前ADO 的 使 用 状 况， 将RDO2.0 或DAO3.5 同ADO 做 比 较 显 得 意 义 并 不 很 大。 所 以 回 答 是： 如 果 感 觉 方 便， 还 是 尽 早 转 移 到ADO， 这 意 味 着 应 用 软 件 对 各 种 数 据 访 问 接 口 将 继 续 予 以 支 持。ADO 是 独 立 于 开 发 工 具 和 开 发 语 言 的 简 单 而 且 容 易 使 用 的 数 据 接 口， 同ADO 相 比， 其 他 数 据 访 问 接 口 都 会 黯 然 逊 色。 ---- 所 有 的 数 据 源 都 可 以 通 过ADO 来 访 问， 在 今 天 已 逐 渐 成 为 现 实。 VB 访 问 数 据 库 技 术 的 历 史
---- 综 观 过 去 的 几 年， 使 用Visual Basic 的 客 户 曾 设 计 出 数 不 胜 数 的 程 序 和 组 件 来 建 立 商 务 解 决 方 案。 大 约80% 以 上 的 应 用 程 序 是 用 来 访 问 以 下 这 些 数 据 的：ASCII 文 本 文 件、SQL 数 据 库 以 及 大 型 机 数 据 库。 早 期 的Visual Basic 数 据 访 问 工 具 只 是 简 单 的ASCII 文 件 的 访 问 工 具， 极 少 数SQL Server 的 前 端 应 用 程 序 是 使 用 鲜 为 人 知 的 数 据 接 口VBSQL 编 写 的。 然 而， 在Visual Basic 3.0 时 代 许 多 用 户 强 调 需 转 移 访 问 包 含 远 程 数 据 源 的ISAM 数 据， 为 此Microsoft 设 计 了Microsoft Jet Database Engine （ 或 简 称 为Jet） 和Data Access Object(DAO)， 使 得Visual Basic Access 开 发 人 员 很 容 易 地 同Jet 接 口。 直 至 前 两 年， 对Visual Basic 和 其 使 用 者 的 需 求 又 包 含 了 更 快 的 访 问 远 程 数 据 和 对ODBC 数 据 源 访 问 的 优 化。
---- 当 选 择 在 此 讨 论 的 哪 种 技 术 是 最 佳 技 术 时， 需 要 注 意 两 点： 代 码 的 重 用 和 开 发 者 实 现 选 择 的 数 据 库 访 问 方 案 的 能 力。 设 计 者 常 常 为 实 现 或 追 求 一 种 更 特 别 的 性 能 而 使 用 有 更 多 控 件 的 奇 异 方 案， 这 样 设 计 出 来 的 应 用 程 序 只 会 支 持 起 来 更 复 杂 或 维 护 时 更 困 难。 开 发 人 员 和 他 们 的 管 理 人 员 需 要 在Visual Basic 的 开 发 小 组 和 各 种 数 据 库 接 口 开 发 小 组 中 注 意 避 免 这 种 趋 势。 这 些 小 组 协 调 努 力 简 化VB5 中 的 数 据 访 问 接 口 会 使 程 序 的 安 全 性 和 速 度 更 好。VB5 也 包 含 了 全 新 的 查 询 连 接 生 成 器， 即 User Connection 设 计 器， 它 使 用 Visual Basic 新 的 ActiveX 设 计 器 体 系 结 构， 对 要 编 程 的 数 据 访 问 提 供 设 计 时 的 支 持。 允 许 在 设 计 时 创 建 连 接 并 查 询 对 象（ 基 于 RDO rdoConnection 和 rdoQuery 对 象）。 并 把 这 些 连 接 和 查 询 对 象 当 作 工 程 级 对 象。 可 预 先 设 置 属 性、 定 义 新 属 性 和 方 法 并 给 对 象 编 写 代 码 来 捕 捉 事 件。 ---- 这 不 仅 为 响 应 由 连 接 和 查 询 而 引 起 的 事 件， 而 且 为 在 运 行 时 调 用 已 有 存 储 过 程 和 用 户 定 义 的 查 询 提 供 了 简 单 的 方 法。 使 用User Connection 设 计 器 这 种 技 术， 代 码 可 减 少10 倍， 性 能 却 没 有 任 何 损 失。 ---- 现 在 用VB5 来 建 服 务 器 端 组 件 或 前 端 应 用 程 序， 可 以 使 用 的 数 据 库 接 口 方 案 至 少 有 九 种。 每 一 种 方 案 都 可 满 足 用 户 特 定 的 需 要， 比 如 特 殊 的 数 据 源 和 用 户 开 发 的 技 能 等。 Visual Basic 访 问 数 据 库 的 现 状
---- 下 面 的 表 格 列 出 了 目 前 在VB5 中 有 效 的 数 据 访 问 接 口 方 法， 一 部 分 是 简 单 的 应 用 程 序 接 口 界 面（APIs）, 但 大 部 分 是 组 件 对 象 模 型 界 面（COM）。 这 两 类 数 据 库 接 口 界 面 事 实 上 在 任 何 一 种 开 发 语 言 中 都 包 括。
接 口 界 面 访 问 对 象 16/32 位 支 持
VBSQL 通 过DB-Library 访 问 微 软 的SQL Server 16 位 和32 位
ODBC API 任 何 一 种ODBC 数 据 源 16 位 和32 位
DAO/Jet 本 地 的Jet/Access .MDB、 顺 序 索 引 数 据 库（ISAM） 和 任 何ODBC 数 据 源。 16 位 和32 位
DAO/ODBC Direct 任 何 一 种ODBC 数 据 源（ 经 过RDO） 32 位
RDO 2.0 任 何 一 种ODBC 数 据 源（Level Ⅰ 或 Ⅱ） 32 位
ADO * 任 何 一 种ODBC 数 据 源 和 任 何 经 过OLE DB 界 面 接 口 的 数 据 源 32 位
---- *ADO 不 包 括 在VB5 中， 目 前 的 许 多 网 络 产 品 支 持ADO 如：IIS、Visual Studio 等， 也 会 发 行 在VB 的 下 一 版 本VB6 中。 ---- 上 表 列 出 了 用VB5 程 序 代 码 访 问 数 据 库 的 几 种 接 口 界 面， 但 是 许 多 开 发 人 员 也 使 用 一 些 数 据 库 绑 定 的 控 件 来 实 现 一 些 简 单 重 复 的 功 能 如： 用 户 数 据 的 输 入、 显 示、 筛 选 等 接 口 界 面。VB 也 支 持 对 多 种 数 据 源 访 问 的 控 件， 这 些 控 件 在VB 和COM 界 面 接 口 之 间 起 着 媒 介 作 用。 这 些 控 件 提 供 了 一 种 减 少 代 码 实 现 数 据 访 问 的 途 径， 该 方 法 简 化 了 代 码 并 使 程 序 员 不 必 亲 自 处 理 检 索 和 更 新 数 据 的 底 层 结 构 和 机 制。 它 赋 予 程 序 员 很 大 的 灵 活 性， 因 为 可 以 使 用 同 样 的 对 象、 属 性 和 方 法 来 处 理 各 种 不 同 的 数 据 库 格 式。 同 时， 如 果 从 一 种 数 据 库 格 式 变 到 另 一 种 格 式（ 例 如， 将 本 地 的 Microsoft Access 数 据 库 转 换 为 网 络 上 的 SQL Server 数 据 库）， 只 需 变 动 少 量 的 代 码 就 可 以 适 应 这 种 改 变。 甚 至 可 以 创 建 这 样 的 应 用 程 序， 在 单 一 的 查 询 或 报 表 中 连 接 来 自 多 个 不 同 数 据 库 的 表。 数 据 绑 定 控 件 访 问 对 象 16/32 位 支 持
Data Control DAO/Jet 数 据 界 面 接 口 16 位 和32 位
Data Control/ODBC Direct DAO/ODBC Direct 数 据 界 面 接 口 32 位
RemoteData Control/RDC RDO 数 据 界 面 接 口 32 位
Advanced Data Connector/ADC * ADO 数 据 界 面 接 口 32 位
---- *ADO 不 包 括 在VB5 中， 目 前 的 许 多 网 络 产 品 支 持ADO 如：IIS、Visual Studio 等， 也 会 发 行 在VB 的 下 一 版 本VB6 中。 ---- 经 过 数 年 发 展，ODBC 技 术 日 臻 完 善 已 成 为 访 问 远 程 数 据 的 主 要 方 法， 而Jet 成 为 本 地Jet 和ISAM 数 据 接 口 的 首 选 方 案。 虽 然 这 些 方 法 在 不 同 程 度 上 有 功 能 交 迭 的 地 方， 在 论 证 选 用 数 据 库 访 问 的 方 法 时， 主 要 还 应 满 足 用 户 在 特 殊 应 用 程 序 中 对 具 体 数 据 接 口 的 访 问。 并 不 是 所 有 人 对 数 据 访 问 中 的 一 些 缩 写 词 都 了 解。 下 表 从VB 的 观 点 简 要 介 绍 这 些 缩 写 词 的 含 义 和 各 种 数 据 访 问 方 法 的 功 能 比 较。 数据访问接口 功 能 及 含 义
ADC 高 级 数 据 连 接 器（Advanced Data Connector）： 提 供 绑 定ADO 数 据 源 到 窗 体 的 数 据 绑 定 控 件 上。ADC 主 要 是 一 种 直 接 访 问 或 者 通 过ADO 访 问 远 程 OLE DB 对 象 的 一 种 技 术， 它 也 支 持 主 要 应 用 在 微 软IE 浏 览 器 上 的 数 据 绑 定 控 件。 它 是 特 地 为Web 上 的 浏 览 器 为 基 础 的 应 用 程 序 而 设 计 的。
ADO Active 数 据 对 象（Active Data Objects）：ADO 实 际 是 一 种 提 供 访 问 各 种 数 据 类 型 的 连 接 机 制。ADO 设 计 为 一 种 极 简 单 的 格 式， 通 过ODBC 的 方 法 同 数 据 库 接 口。 可 以 使 用 任 何 一 种ODBC 数 据 源， 即 不 止 适 合 于SQL Server、Oracle、Access 等 数 据 库 应 用 程 序， 也 适 合 于Excel 表 格、 文 本 文 件、 图 形 文 件 和 无 格 式 的 数 据 文 件。ADO 是 基 于OLE-DB 之 上 的 技 术， 因 此ADO 通 过 其 内 部 的 属 性 和 方 法 提 供 统 一 的 数 据 访 问 接 口 方 法。
DAO 数 据 访 问 对 象（Data Access Objects）： 是 一 种 面 向 对象的界面接口。 通 过DAO/Jet 功 能 可 以 访 问ISAM 数 据 库， 使 用DAO/ ODBC Direct 功 能 可 以 实 现 远 程RDO 功 能。 使 用DAO 的 程 序 编 码 非 常 简 单，DAO 提 供 丰 富 的 游 标（Cursor） 类 型 的 结 果 集 和 非 游 标（Cursor-Less） 类 型 的 结 果 集， 同DDL（ 数 据 描 述 语 言） 的 功 能 很 类 似。
DAO 模 型 是 设 计 关 系 数 据 库 系 统 结 构 的 对 象 类 的 集 合。 它 们 提 供 了 完 成 管 理 这 样 一 个 系 统 所 需 的 全 部 操 作 的 属 性 和 方 法， 包 括 创 建 数 据 库， 定 义 表、 字 段 和 索 引， 建 立 表 间 的 关 系， 定 位 和 查 询 数 据 库 等 工 具。
Jet 数 据 连 接 性 引 擎 技 术（Joint Engine Technology）： 是 一 种 基 于 工 作 站 通 过DAO 的 数 据 库 访 问 机 制。 虽 然 可 以 通 过 微 软Access 提 供 的ODBC 驱 动 程 序 访 问Jet 数 据 库， 但 使 用 这 些 驱 动 程 序 在 功 能 上 有 所 限 制。Jet 机 制 有 自 己 的 查 询 和 结 果 集 处 理 功 能， 并 可 对 同 种 或 异 种 数 据 源 作 查 询 处 理。
ODBC 开 放 式 的 数 据 库 连 接（Open Database Connectivity）： 是 一 种 公 认 的 关 系 数 据 源 的 接 口 界 面。 它 快 而 轻 并 且 提 供 统 一 接 口 的 界 面，ODBC 对 任 何 数 据 源 都 未 作 优 化。
ODBC Direct 是 一 种 基 于DAO 对 象 的 新 的DAO 模 式， 其 方 法 和 属 性 与RDO 功 能 相 同。 使 用 在 有DAO 代 码 存 在 的 场 合， 可 用 来 访 问 远 程 数 据 源。
OLE DB 是 一 种 底 层 数 据 访 问 界 面 接 口。 是 用 于 第 三 方 驱 动 程 序 商 家 开 发 输 出 数 据 源 到ADO- 技 术 的 应 用 程 序 或 用 于C++ 的 开 发 者 开 发 定 制 的 数 据 库 组 件。OLE DB 不 能 被VB 直 接 调 用。
RDC 远 程 数 据 访 问 控 件（RemoteData Control）： 是 一 种 对RDO 数 据 绑 定 的 控 件。 可 以 输 出 特 定 的 结 果 集 到 数 据 源 控 件。
RDO 远 程 数 据 对 象（Remote Data Objects）: 远 程 数 据 对 象 和 集 合 为 使 用 代 码 来 创 建 和 操 作 一 个 远 程 ODBC 数 据 库 系 统 的 各 个 部 件 提 供 了 一 个 框 架。 对 象 和 集 合 都 具 有 描 述 数 据 库 的 各 个 部 件 特 征 的 属 性 以 及 用 来 操 作 这 些 部 件 的 方 法。 可 以 在 对 象 和 集 合 之 间 建 立 起 关 系， 这 些 关 系 就 代 表 了 数 据 库 系 统 的 逻 辑 结 构。RDO 是ODBC API 的 一 个 浅 层 界 面 接 口。 是 专 为 访 问 远 程ODBC 关 系 数 据 源 而 设 计 的。
VBSQL 是Visual Basic 结 构 化 查 询 语 言。 是 一 种 基 于API 的 接 口 方 法， 几 乎 与C 的DB-Library API 相 同。VBSQL 只 支 持 微 软 的SQL Server。VBSQL 快 而 且 轻 但 不 支 持 对 象 界 面。
Visual Basic 访 问 数 据 库 的 前 景
---- 近 来 随 着Web 应 用 软 件 的 迅 速 发 展 和 现 有 数 据 存 储 形 式 的 多 种 多 样，Visual Basic 访 问 数 据 库 的 解 决 方 案 面 临 诸 如 快 速 提 取 分 布 于 企 业 内 部 和 外 部 有 用 商 业 信 息 等 的 多 种 挑 战。 为 此Microsoft 提 出 一 种 新 的 数 据 库 访 问 策 略， 即“ 统 一 数 据 访 问”（Universal Data Access） 的 策 略。“ 统 一 数 据 访 问” 提 供 了 高 性 能 的 存 取 包 括 关 系 型 和 非 关 系 型 在 内 的 多 种 数 据 源， 提 供 独 立 于 开 发 工 具 和 开 发 语 言 的 简 单 的 编 程 接 口， 这 些 技 术 使 得 企 业 集 成 多 种 数 据 源、 选 择 更 好 的 开 发 工 具、 应 用 软 件、 操 作 平 台、 建 立 容 易 维 护 的 解 决 方 案 成 为 可 能。
---- “ 统 一 数 据 访 问”（Universal Data Access） 的 基 础 是Microsoft 的 数 据 访 问 组 件。 这 些 组 件 包 括ActiveX Data Objects(ADO)、Remote Data Service（RDS， 也 称“ 高 级 数 据 连 接 器” 或ADC）、OLE DB 和ODBC。
译一下好不好?
的DB_LIBRARY
兄弟我用Connection的Execute方法生成了一个记录集，但在用pRS->RecordCount 时出错，这是为什么？难道这个记录集不可用？