Difference between ADO vs ODBC vs OLE DB

最新推荐文章于 2025-08-20 15:10:31 发布

envykok

最新推荐文章于 2025-08-20 15:10:31 发布

阅读量276

点赞数

分类专栏： SQL Monthly Maintanence 文章标签： interface components database microsoft application 数据库

SQL Monthly Maintanence 专栏收录该内容

10 篇文章

订阅专栏

本文详细对比了ADO（ActiveX Data Objects）、ODBC（Open Database Connectivity）和OLE DB三种数据访问技术的特点和适用场景。介绍了这些技术的历史背景、架构原理以及它们之间的关系，帮助开发者选择最适合项目的数据库访问方式。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

http://mvmnoushad.blogspot.com/2010/01/difference-betwwen-ado-vs-odbc-vs-ole.html

Application --> ADO --> ODBC --> Database

Using this kind of scheme lets you change one of the layers without changing the others (usually).

ODBC is older than OLEDB but is an Industry standard supported by almost everybody. OLEDB is Microsoft only. OLEDB does come with an interface driver itself so you could do the following if you had to.

Application --> ADO --> OLEDB --> ODBC --> Database

If you are using a language that has a direct API then you would be etter off using it as there will be less between you and your data.

Application --> API --> Database

You will get better performance but porting your code to a different data source or programming language would be harder.

ADO = API to OLE DB.
ADO Speed < OLE DB Speed Programming the OLE DB API Directly may take a very long time to master. Explanation from M$.

ActiveX Data Objects (ADO) is a high-level, easy-to-use interface to OLE DB.

OLE DB is a low-level, high-performance interface to a variety of data stores.

ODBC is another low-level, high-performance (maybe not-so high-performance, I think) interface that is designed specifically for relational data stores. ADO provides a layer of abstraction between your client or middle-tier application and the low-level OLE DB interfaces. ADO uses a small set of Automation objects to provide a simple and efficient interface to OLE DB. This interface makes ADO the perfect choice for developers in higher level languages, such as Visual Basic and VBScript, who want to access data without having to learn the intricacies of COM and OLE DB. A Note on Providers from M$: You are strongly encouraged to use one of the native OLE DB Providers instead of the Microsoft Open Database Connectivity (ODBC) Provider. Native OLE DB Providers provide better application stability and performance. If you want more info, go to http://msdn.microsoft.com/data Then drill down from "Data Access->Reference

...

ActiveX Data Objects (ADO)

ADO is the strategic application programming interface (API) to data and information. ADO provides consistent, high-performance access to data and supports a variety of development needs, including the creation of front-end database clients and middle-tier business objects that use applications, tools, languages, or Internet browsers. ADO is designed to be the one data interface needed for single and multi-tier client/server and Web-based data-driven solution development. The primary benefits of ADO are ease of use, high speed, low memory overhead, and a small disk footprint.

ADO provides an easy-to-use interface to OLE DB, which provides the underlying access to data. ADO is implemented minimal network traffic in key scenarios, and a minimal number of layers between the front end and data source-all to provide a lightweight, high-performance interface. ADO is easy to use because it uses a familiar metaphor-the COM automation interface, available from all leading Rapid Application Development (RAD) tools, database tools, and languages on the market today. ADO is a nice wrapper for OLD-DB.

OLE DB

OLE-DB is the Microsoft strategic system-level programming interface to data across the organization. OLE DB is an open specification designed to build on the success of ODBC by providing an open standard for accessing all kinds of data. Whereas ODBC was created to access relational databases, OLE DB is designed for relational and non relational information sources, including mainframe ISAM/VSAM and hierarchical databases; e-mail and file system stores; text, graphical, and geographical data; custom business objects; and more.

OLE DB defines a collection of COM interfaces that encapsulate various database management system services. These interfaces enable the creation of software components that implement such services. OLE DB components consist of data providers, which contain and expose data; data consumers, which use data; and service components, which process and transport data (such as query processors and cursor engines). OLE DB interfaces are designed to help components integrate smoothly so that OLE DB component vendors can bring high-quality OLE DB components to market quickly. In addition, OLE DB includes a bridge to ODBC to enable continued support for the broad range of ODBC relational database drivers available today.

Open Database Connectivity (ODBC)

The ODBC interface is an industry standard and a component of Microsoft Windows Open Services Architecture (WOSA). The ODBC interface makes it possible for applications to access data from a variety of database management systems (DBMSs). ODBC permits maximum interoperability-an application can access data in diverse DBMSs through a single interface. Furthermore, that application will be independent of any DBMS from which it accesses data. Users of the application can add software components called drivers, which create an interface between an application and a specific DBMS.

When should you use OLE-DB, ADO, DAO, or ODBC ?

ADO is a wrapper around OLE-DB so you can use ADO or OLE-DB.

Non-OLE environment : If a database supports ODBC and and that database is on a server that don't support OLE then ODBC is your best choice.

Non-SQL environment : ODBC is designed to work with SQL. If you have non-SQL environment then OLE-DB is better choice.

OLE environment : If you already have ODBC drives then you can use ODBC, otherwise use OLE-DB.

Interoperability required : If you need interoperable database components, then OLE-DB is your best choice.

16-Bit data access support : ADO don't support 16 bit so ODBC is the only choice.

Using multiple databases - If you are using databases that support Microsoft's jet engine then definite choice is ADO or DAO. By using ADO you get workspace level support for transaction. That means you can connect more than one database at a time in an application, which is impossible by using ODBC. You can only connect one database at a time by using ODBC.

...

Chinses Version: http://ce.sysu.edu.cn/hope/Education/ShowArticle.asp?ArticleID=5452

史前
    那时候每个数据库供应商（其实也没几个）
    都有自己的数据库操作API，
    每个应用程序只能使用一个固定的数据库
    想换数据库？没门！你要全部重新写
后来
    X/OPEN和ISO(好像还有IBM)说
    这么乱，程序员怎么活啊
    于是提出了CLI（Call-Level Interface）
    每个数据库的CLI(驱动程序)基本上相同，
    程序员总算好过点了，可是要换数据库，
    你写的程序需要重新编译（或许还要安装）
再后来
    于是ODBC来了，它通过动态装载各个数据库的CLI
    把函数调用转换成每个数据库的CLI调用
    数据库应用程序总算和数据库供应商每什么关系了
再后来
    MS提出了OLE，MS还有了自己的数据库
    (Access/SQL Server)
    MS是老大，这个问题上当然要有自己的看法
    要是还只是提供ODBC，那多没面子
    所以提出了 OleDb,它通过COM接口调用
    OleDb也需要每个数据库提供一个CLI
    （不过有了新名词，叫作Provider)
    MS 给 Access和SqlServer分别写了一个Provider
    不过为了照顾使用ODBC的，也提供了一个ODBC的Provider
    这样那些只提供ODBC的数据库也可以通过OleDb访问
    不过这样效率就稍微低了(因为要经过两层么)
    所以现在有些数据库会提供自己的Provider
再后来
    MS说OleDb的接口太复杂了
    程序员也就调调QUERY
    没必要搞这么复杂吧
    于是提出了ADO,ADO 通过在OleDb上面封装
    简化了使用方法,程序员在操作数据库上总算是解放了
新世纪终于到来了
    MS也发明了.NET,为了适应新世纪新潮流
    也提出了 ADO.NET