blocks|key|362458|text|在非常基本的层面上，这些只是不同数据源(即数据库)的不同API。OLE+DB比较新，而且可以说是更好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|362459|你可以在维基百科上阅读更多关于这两个方面的内容：|362460|362461|OLE+DB|ordered-list-item|offset|length|362462|ODBC|362463|362464|也就是说，您可以使用ODBC驱动程序或OLE+DB驱动程序连接到同一数据库。在这些情况下，数据库行为的差异就是您的书所指的。|362465|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/OLE_DB|1|http://en.wikipedia.org/wiki/Open_Database_Connectivity^0|0|0|0|0|6|0|0|0|4|1|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|10|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|11|8|@]|9|@$H|12|I|13|1|14]]|A|$]]|$1|J|3|K|5|G|7|15|8|@]|9|@$H|16|I|17|1|18]]|A|$]]|$1|L|3|-4|5|6|7|19|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|1A|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]]|P|$Q|$5|R|S|T|A|$U|V]]|W|$5|R|S|T|A|$U|X]]]]

On a very basic level those are just different APIs for the different data sources (i.e. databases). OLE DB is newer and arguably better.

You can read more on both in Wikipedia:

<ol>
<li><a href="http://en.wikipedia.org/wiki/OLE_DB" rel="nofollow noreferrer">OLE DB</a></li>
<li><a href="http://en.wikipedia.org/wiki/Open_Database_Connectivity" rel="nofollow noreferrer">ODBC</a></li>
</ol>

I.e. you could connect to the same database using an ODBC driver or OLE DB driver. The difference in the database behaviour in those cases is what your book refers to.

blocks|key|362471|text|我不确定所有的细节，但我的理解是，OLE+DB和ODBC是两个API，可用于连接到各种类型的数据库，而不必处理每个数据库的所有实现特定细节。根据the+Wikipedia+article+on+OLE+DB的说法，OLE+DB是微软对ODBC的继任者，它提供了一些使用ODBC可能无法实现的功能，例如将电子表格作为数据库源进行访问。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|362472|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/OLE_DB^0|20|V|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

I'm not sure of all the details, but my understanding is that OLE DB and ODBC are two APIs that are available for connecting to various types of databases without having to deal with all the implementation specific details of each. According to <a href="http://en.wikipedia.org/wiki/OLE_DB" rel="nofollow noreferrer" title="Wikipedia article on OLE DB">the Wikipedia article on OLE DB</a>, OLE DB is Microsoft's successor to ODBC, and provides some features that you might not be able to do with ODBC such as accessing spreadsheets as database sources.

blocks|key|364314|text|ODBC:-仅适用于关系数据库(Sql+Server、Oracle等)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|364315|OLE+DB:-适用于关系数据库和非关系数据库。(Oracle、Sql-Server、Excel、raw文件等)|364316|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

ODBC:- Only for relational databases (Sql Server, Oracle etc)

OLE DB:- For both relational and non-relational databases. (Oracle, Sql-Server, Excel, raw files, etc)

blocks|key|363897|text|根据,+a+book+by+Jason+T.+Roff,+published+by+O'Reilly+Media+in+2001+(这里有很好的图表)，他准确地说出了MOZILLA所说的话。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|363898|(直接从那本书的第7页)|363899|363900|blockquote|363901|363902|363903|ODBC仅提供对关系数据库的访问|unordered-list-item|363904|OLE+DB提供以下功能|363905|对数据的访问，无论其格式或位置如何|363906|对ODBC数据源和ODBC+|363907|的完全访问|363908|363909|363910|​|363911|因此，OLE似乎通过ODBC驱动器层与基于SQL的数据源进行交互。|363912|363913|📷|atomic|363914|363915|我不是100%25确定这个图像是正确的。我不确定的两个连接是通过ADO+C-api的ADO.NET和通过ODBC到基于SQL的数据源的OLE+DB+(因为在this+diagram中，作者没有将OLE+DB的访问通过ODBC，我认为这是一个错误)。|363916|entityMap|0|LINK|mutability|MUTABLE|url|http://books.google.ca/books?id=JTKX7OUqCEMC&lpg=PP1&dq=contact%2520jason%2520roff%2520activex%2520data%2520objects&pg=PA12|1|IMAGE|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/d0e3a0265594493d849166602ebeeeae.png|imageAlt|2|http://books.google.ca/books?id=JTKX7OUqCEMC&lpg=PP1&dq=contact%2520jason%2520roff%2520activex%2520data%2520objects&pg=PA12^0|2|1Q|0|0|0|0|0|0|0|0|1|1|1|1|0|0|0|0|0|0|1|1|0|0|24|C|2|0^^$0|@$1|2|3|4|5|6|7|1O|8|@]|9|@$A|1P|B|1Q|1|1R]]|C|$]]|$1|D|3|E|5|6|7|1S|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|1T|8|@]|9|@]|C|$]]|$1|G|3|-4|5|H|7|1U|8|@]|9|@]|C|$]]|$1|I|3|-4|5|6|7|1V|8|@]|9|@]|C|$]]|$1|J|3|-4|5|6|7|1W|8|@]|9|@]|C|$]]|$1|K|3|L|5|M|7|1X|8|@]|9|@]|C|$]]|$1|N|3|O|5|M|7|1Y|8|@]|9|@]|C|$]]|$1|P|3|Q|5|M|7|1Z|8|@]|9|@]|C|$]]|$1|R|3|S|5|M|7|20|8|@]|9|@]|C|$]]|$1|T|3|U|5|M|7|21|8|@]|9|@]|C|$]]|$1|V|3|-4|5|6|7|22|8|@]|9|@]|C|$]]|$1|W|3|-4|5|6|7|23|8|@]|9|@]|C|$]]|$1|X|3|Y|5|6|7|24|8|@]|9|@]|C|$]]|$1|Z|3|10|5|6|7|25|8|@]|9|@]|C|$]]|$1|11|3|Y|5|6|7|26|8|@]|9|@]|C|$]]|$1|12|3|13|5|14|7|27|8|@]|9|@$A|28|B|29|1|2A]]|C|$]]|$1|15|3|Y|5|6|7|2B|8|@]|9|@]|C|$]]|$1|16|3|17|5|6|7|2C|8|@]|9|@$A|2D|B|2E|1|2F]]|C|$]]|$1|18|3|-4|5|6|7|2G|8|@]|9|@]|C|$]]]|19|$1A|$5|1B|1C|1D|C|$1E|1F]]|1G|$5|1H|1C|1I|C|$1J|1K|1L|-4]]|1M|$5|1B|1C|1D|C|$1E|1N]]]]

According to <a href="http://books.google.ca/books?id=JTKX7OUqCEMC&amp;lpg=PP1&amp;dq=contact%20jason%20roff%20activex%20data%20objects&amp;pg=PA12" rel="noreferrer">ADO: ActiveX Data Objects, a book by Jason T. Roff, published by O'Reilly Media in 2001</a> (excellent diagram here), he says precisely what MOZILLA said.

(directly from page 7 of that book)

<blockquote>
 <ul>
 <li>ODBC provides access only to relational databases</li></li>
 <li>OLE DB provides the following features
 
 <ul>
 <li>Access to data regardless of its format or location</li></li>
 <li>Full access to ODBC data sources and ODBC drivers</li></li>
 </ul></li>
 </ul>
</blockquote>

So it would seem that OLE DB interacts with SQL-based datasources THRU the ODBC driver layer.

<img src="https://bobobobo.files.wordpress.com/2009/07/db-full-diagram.png" alt="alt text">

I'm not 100% sure this image is correct. The two connections I'm not certain about are ADO.NET thru ADO C-api, and OLE DB thru ODBC to SQL-based data source (because in <a href="http://books.google.ca/books?id=JTKX7OUqCEMC&amp;lpg=PP1&amp;dq=contact%20jason%20roff%20activex%20data%20objects&amp;pg=PA12" rel="noreferrer">this diagram</a> the author doesn't put OLE DB's access thru ODBC, which I believe is a mistake).

blocks|key|362521|text|以下是我的理解(非权威)：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|362522|ODBC是一种与技术无关的开放标准，大多数软件供应商都支持它。OLEDB是COM时代特定于技术的微软应用编程接口(COM在.NET之前是一种组件和互操作性技术)|362523|在某种程度上，各种数据源供应商(例如Oracle等)愿意与Microsoft数据消费者兼容，为他们的产品开发了OLEDB提供程序，但在大多数情况下，OLEDB仍然是Microsoft独有的标准。现在，大多数Microsoft数据源都允许ODBC和OLEDB访问，主要是为了与遗留的ODBC数据使用者兼容。此外，还存在用于ODBC的OLEDB提供程序(包装器)，它允许用户使用OLEDB访问ODBC数据源。|362524|就功能而言，OLEDB比ODBC丰富得多，但存在“一环一规则”综合症(过于通用、过于复杂、不固执己见)。|362525|在非Microsoft的世界中，基于ODBC的数据提供程序和客户机被广泛使用，而且不会再有用武之地。|362526|在微软内部，泡泡OLEDB正在逐步淘汰，取而代之的是原生.NET+API，这些API建立在数据源的原生传输层之上(例如，用于MS+SQL+Server的TDS+)。|362527|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

Here's my understanding (non-authoritative):

ODBC is a technology-agnostic open standard supported by most software vendors.
OLEDB is a technology-specific Microsoft's API from the COM-era (COM was a component and interoperability technology before .NET)

At some point various datasouce vendors (e.g. Oracle etc.), willing to be compatible with Microsoft data consumers, developed OLEDB providers for their products, but for the most part OLEDB remains a Microsoft-only standard. Now, most Microsoft data sources allow both ODBC and OLEDB access, mainly for compatibility with legacy ODBC data consumers. Also, there exists OLEDB provider (wrapper) for ODBC which allows one to use OLEDB to access ODBC data sources if one so wishes.

In terms of the features OLEDB is substantially richer than ODBC but suffers from one-ring-to-rule-them-all syndrome (overly generic, overcomplicated, non-opinionated).

In non-Microsoft world ODBC-based data providers and clients are widely used and not going anywhere.

Inside Microsoft bubble OLEDB is being phased out in favor of native .NET APIs build on top of whatever the native transport layer for that data source is (e.g. TDS for MS SQL Server).

blocks|key|3156761|text|两者都是数据提供程序(您的代码将用来与数据源对话的API)。Oledb于1998年引入，旨在取代ODBC+(于1992年引入)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3156762|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Both are data providers (API that your code will use to talk to a data source). Oledb which was introduced in 1998 was meant to be a replacement for ODBC (introduced in 1992)

blocks|key|362535|text|在微软的网站上，展示了本地OLEDB+Provider直接应用于SQL+server，以及另一种称为OLEDB+Provider+for+ODBC访问其他数据库的OLEDB+provider，如Sysbase、DB2等。有关详细信息，请参阅Distributed+Queries+on+MSDN。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|362536|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/ms188721(v=SQL.105).aspx^0|3C|R|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

At Microsoft website, it shows that native OLEDB provider is applied to SQL server directly and another OLEDB provider called OLEDB Provider for ODBC to access other Database, such as Sysbase, DB2 etc. There are different kinds of component under OLEDB Provider. See <a href="http://msdn.microsoft.com/en-us/library/ms188721(v=SQL.105).aspx" rel="nofollow noreferrer">Distributed Queries on MSDN</a> for more.

blocks|key|3156792|text|要了解M$发明OLEDB的原因，您不能将OLEDB与ODBC进行比较。相反，您应该将OLEDB与DAO、RDO或ADO进行比较。后者很大程度上依赖于SQL。但是，OLEDB依赖于COM。但是ODBC已经存在很多年了，所以有一个OLEDB-ODBC桥来弥补这一点。我认为当M$发明OLEDB时，有一个很大的图景。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3156793|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

To know why M$ invents OLEDB, you can't compare OLEDB with ODBC. Instead, you should compare OLEDB with DAO,RDO, or ADO. The latter largely relies on SQL. However, OLEDB relies on COM. But ODBC is already there many years, so there's a OLEDB-ODBC bridges to remedy this. I think there's a big picture when M$ invents OLEDB.

blocks|key|3156815|text|ODBC只适用于关系型数据库，不能用于非关系型数据库，如Ms+Excel文件。在那里Olebd可以做任何事。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3156816|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

ODBC works only for relational databases, it can't works with non-relational databases such as Ms Excel files. Where Olebd can do everything.

blocks|key|362571|text|·2011年8月:微软不推荐使用+OLE+DB+(Microsoft+is+Aligning+with+ODBC+for+Native+Relational+Data+Access)|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|362572|·2017年10月:微软不推荐使用+OLE+DB+(Announcing+the+new+release+of+OLE+DB+Driver+for+SQL+Server)|362573|entityMap|0|LINK|mutability|MUTABLE|url|https://blogs.msdn.microsoft.com/sqlnativeclient/2011/08/29/microsoft-is-aligning-with-odbc-for-native-relational-data-access/|1|https://blogs.msdn.microsoft.com/sqlnativeclient/2017/10/06/announcing-the-new-release-of-ole-db-driver-for-sql-server/^0|B|5|P|1T|0|0|C|5|Q|1M|1|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]]|D|@$9|U|A|V|1|W]]|E|$]]|$1|F|3|G|5|6|7|X|8|@$9|Y|A|Z|B|C]]|D|@$9|10|A|11|1|12]]|E|$]]|$1|H|3|-4|5|6|7|13|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]|P|$5|K|L|M|E|$N|Q]]]]

• August, 2011: Microsoft deprecates OLE DB (<a href="https://blogs.msdn.microsoft.com/sqlnativeclient/2011/08/29/microsoft-is-aligning-with-odbc-for-native-relational-data-access/" rel="noreferrer">Microsoft is Aligning with ODBC for Native Relational Data Access</a>)

• October, 2017: Microsoft undeprecates OLE DB (<a href="https://blogs.msdn.microsoft.com/sqlnativeclient/2017/10/06/announcing-the-new-release-of-ole-db-driver-for-sql-server/" rel="noreferrer">Announcing the new release of OLE DB Driver for SQL Server</a>)

blocks|key|364014|text|ODBC和OLE+DB是两种相互竞争的数据访问技术。特别是关于SQL+Server，Microsoft已经将这两个方向都作为其首选的未来方向进行了推广-尽管时间不同。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|364015|ODBC|364016|ODBC是一个行业范围的标准接口，用于访问表形式的数据。它主要是为数据库开发的，并以记录集合的形式呈现数据，每个记录集合被分组到一个字段集合中。每个字段都有自己的数据类型，适合它所包含的数据类型。每个数据库供应商(微软、甲骨文、Postgres、…)为他们的数据库提供ODBC驱动程序。|364017|还有一些对象的ODBC驱动程序，尽管它们不是数据库表，但它们非常相似，因此以同样的方式访问数据很有用。例如电子表格、CSV文件和柱状报告。|364018|OLE+DB|364019|OLE+DB是一种用于访问数据的Microsoft技术。与ODBC不同，它既包含表状数据，也包含非表状数据，如电子邮件消息、网页、Word文档和文件目录。但是，它是面向过程的，而不是面向对象的，并且被认为是用于开发对数据源的访问的相当困难的接口。为了克服这一点，ADO被设计为OLE+DB之上的面向对象的层，并提供一种更简单、更高级别(尽管功能仍然非常强大)的工作方式。ADO的最大优势在于，您可以使用它来操作特定于给定类型的数据源的属性，就像您可以使用它来访问那些适用于所有数据源类型的属性一样简单。你不会局限于一些不令人满意的最低公分母。|364020|虽然所有数据库都有ODBC驱动程序，但并不是所有数据库都有OLE+DB驱动程序。但是，在OLE和ODBC之间有一个可用的接口，如果您想以类似于OLE+DB的方式访问它们，可以使用该接口。此接口称为MSDASQL+(Microsoft+OLE+DB+provider+for+ODBC)。|364021|SQL+Server数据访问技术|364022|由于SQL+Server是(1)由Microsoft开发的，(2)是Microsoft数据库平台，因此ODBC和OLE+DB都是非常适合它的。|364023|364024|由于所有其他数据库平台都有ODBC接口，因此Microsoft显然必须为SQL+Server提供一个接口。除此之外，DAO是Microsoft+Access中最初的默认技术，它使用ODBC作为与所有外部数据源对话的标准方式。这使得ODBC接口成为一个必须满足的条件。随SQL+Server+2000一起发布的SQL+Server版本6+ODBC驱动程序仍然存在。更新版本已经发布，以处理后续版本中出现的新数据类型、连接技术、加密、HA/DR等。截至2018年9月7日，最新版本是v13.1“ODBC+Driver+for+SQL+Server”，于2018年3月23日发布。|364025|OLE+DB|364026|这是微软自己的技术，大约在2002+-+2005年间，他们一直在大力推广这项技术，以及它附带的ADO层。他们显然希望它能成为首选的数据访问技术。(他们甚至使ADO成为Access+2002/2003中访问数据的默认方法。)然而，最终很明显，这不会发生，原因有很多，例如：|364027|364028|DAO/+ODBC比|unordered-list-item|364029|
|364030|/OLE+DB更快，而且还完全集成到MS+Access中，因此不会自然死亡；|364031|364032|微软正在开发的新技术，特别是ADO.NET，也可以直接与ODBC对话。ADO.NET也可以直接与OLE+DB对话(因此使其陷入困境)，但它并不(与ADO不同)完全依赖于它。|364033|364034|由于这些原因，微软实际上在v11+(SQL+Server2012)之后发布了deprecated+OLE+DB+as+a+data+access+technology+For+SQL+Server。在此之前的几年里，他们一直在生产和更新支持ODBC和OLE+DB技术的SQL+Server+Native+Client。然而，在2012年底，他们宣布将在SQL+Server中为本地关系数据访问与ODBC保持一致，并鼓励其他所有人也这样做。他们进一步指出，v11/SQL+Server+2012之后的SQL+Server版本将主动不支持OLE+DB！|offset|length|364035|这一声明激起了一场抗议风暴。人们不知所措，不明白为什么微软突然放弃了一项他们花了多年让他们承诺的技术。此外，SSAS/SSRS和SSIS是MS编写的与SQL+Server紧密链接的应用程序，它们完全或部分依赖于OLE+DB。另一个抱怨是，OLE+DB具有某些可取的功能，而这些功能似乎不可能移植回ODBC+-毕竟，OLE+DB有许多优点。|364036|2017年10月，微软退让，officially+un-deprecated+OLE+DB。他们宣布即将推出新的驱动程序(MSOLEDBSQL)，该驱动程序将具有Native+Client+11的现有功能集，并将引入多子网故障转移和TLS+1.2支持。该驱动程序于2018年3月发布。|364037|entityMap|0|LINK|mutability|MUTABLE|url|https://blogs.msdn.microsoft.com/sqlnativeclient/2011/08/29/microsoft-is-aligning-with-odbc-for-native-relational-data-access/|1|https://blogs.msdn.microsoft.com/sqlnativeclient/2017/10/06/announcing-the-new-release-of-ole-db-driver-for-sql-server/^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|12|19|0|0|0|E|V|1|0^^$0|@$1|2|3|4|5|6|7|1S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1T|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1U|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1V|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1W|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1X|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|20|8|@]|9|@]|A|$]]|$1|R|3|C|5|6|7|21|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|22|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|23|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|24|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|25|8|@]|9|@]|A|$]]|$1|Z|3|10|5|11|7|26|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|27|8|@]|9|@]|A|$]]|$1|14|3|15|5|11|7|28|8|@]|9|@]|A|$]]|$1|16|3|13|5|6|7|29|8|@]|9|@]|A|$]]|$1|17|3|18|5|11|7|2A|8|@]|9|@]|A|$]]|$1|19|3|-4|5|6|7|2B|8|@]|9|@]|A|$]]|$1|1A|3|1B|5|6|7|2C|8|@]|9|@$1C|2D|1D|2E|1|2F]]|A|$]]|$1|1E|3|1F|5|6|7|2G|8|@]|9|@]|A|$]]|$1|1G|3|1H|5|6|7|2H|8|@]|9|@$1C|2I|1D|2J|1|2K]]|A|$]]|$1|1I|3|-4|5|6|7|2L|8|@]|9|@]|A|$]]]|1J|$1K|$5|1L|1M|1N|A|$1O|1P]]|1Q|$5|1L|1M|1N|A|$1O|1R]]]]

ODBC and OLE DB are two competing data access technologies. Specifically regarding SQL Server, Microsoft has promoted both of them as their Preferred Future Direction - though at different times.

<h1>ODBC</h1>

ODBC is an industry-wide standard interface for accessing table-like data. It was primarily developed for databases and presents data in collections of records, each of which is grouped into a collection of fields. Each field has its own data type suitable to the type of data it contains.
Each database vendor (Microsoft, Oracle, Postgres, …) supplies an ODBC driver for their database. 

There are also ODBC drivers for objects which, though they are not database tables, are sufficiently similar that accessing data in the same way is useful. Examples are spreadsheets, CSV files and columnar reports.

<h1>OLE DB</h1>

OLE DB is a Microsoft technology for access to data. Unlike ODBC it encompasses both table-like and non-table-like data such as email messages, web pages, Word documents and file directories. However, it is procedure-oriented rather than object-oriented and is regarded as a rather difficult interface with which to develop access to data sources. To overcome this, ADO was designed to be an object-oriented layer on top of OLE DB and to provide a simpler and higher-level – though still very powerful – way of working with it. ADO’s great advantage it that you can use it to manipulate properties which are specific to a given type of data source, just as easily as you can use it to access those properties which apply to all data source types. You are not restricted to some unsatisfactory lowest common denominator.

While all databases have ODBC drivers, they don’t all have OLE DB drivers. There is however an interface available between OLE and ODBC which can be used if you want to access them in OLE DB-like fashion. This interface is called MSDASQL (Microsoft OLE DB provider for ODBC). 

<h1>SQL Server Data Access Technologies</h1>

Since SQL Server is (1) made by Microsoft, and (2) the Microsoft database platform, both ODBC and OLE DB are a natural fit for it.

<h2>ODBC</h2>

Since all other database platforms had ODBC interfaces, Microsoft obviously had to provide one for SQL Server. In addition to this, DAO, the original default technology in Microsoft Access, uses ODBC as the standard way of talking to all external data sources. This made an ODBC interface a sine qua non.
The version 6 ODBC driver for SQL Server, released with SQL Server 2000, is still around. Updated versions have been released to handle the new data types, connection technologies, encryption, HA/DR etc. that have appeared with subsequent releases. As of 09/07/2018 the most recent release is v13.1 “ODBC Driver for SQL Server”, released on 23/03/2018.

<h2>OLE DB</h2>

This is Microsoft’s own technology, which they were promoting strongly from about 2002 – 2005, along with its accompanying ADO layer. They were evidently hoping that it would become the data access technology of choice. (They even made ADO the default method for accessing data in Access 2002/2003.) However, it eventually became apparent that this was not going to happen for a number of reasons, such as:

<ol>
<li>The world was not going to convert to Microsoft technologies and
away from ODBC;</li>
<li>DAO/ODBC was faster than ADO/OLE DB and was also thoroughly integrated into MS Access, so wasn’t going to die a natural death;</li>
<li>New technologies that were being developed by Microsoft, specifically ADO.NET, 
could also talk directly to ODBC. ADO.NET could talk directly to OLE
DB as well (thus leaving ADO in a backwater), but it was not (unlike
ADO) solely dependent on it.</li>
</ol>

For these reasons <a href="https://hal2020.com/2011/09/25/ole-db-and-sql-server-history-end-game-and-some-microsoft-dirt/" rel="noreferrer">and others</a>, Microsoft actually <a href="https://blogs.msdn.microsoft.com/sqlnativeclient/2011/08/29/microsoft-is-aligning-with-odbc-for-native-relational-data-access/" rel="noreferrer">deprecated OLE DB as a data access technology</a> for SQL Server releases after v11 (SQL Server 2012). For a couple of years before this point, they had been producing and updating the SQL Server Native Client, which supported both ODBC and OLE DB technologies. In late 2012 however, they announced that they would be aligning with ODBC for native relational data access in SQL Server, and encouraged everybody else to do the same. They further stated that SQL Server releases after v11/SQL Server 2012 would actively not support OLE DB!

This announcement provoked a storm of protest. People were at a loss to understand why MS was suddenly deprecating a technology that they had spent years getting them to commit to. In addition, SSAS/SSRS and SSIS, which were MS-written applications intimately linked to SQL Server, were wholly or partly dependent on OLE DB. Yet another complaint was that OLE DB had certain desirable features which it seemed impossible to port back to ODBC – after all, OLE DB had many good points.

In October 2017, Microsoft relented and <a href="https://blogs.msdn.microsoft.com/sqlnativeclient/2017/10/06/announcing-the-new-release-of-ole-db-driver-for-sql-server/" rel="noreferrer">officially un-deprecated OLE DB</a>. They announced the imminent arrival of a new driver (MSOLEDBSQL) which would have the existing feature set of the Native Client 11 and would also introduce multi-subnet failover and TLS 1.2 support. The driver was released in March 2018.

I was reading a MS Excel help article about pivotcache and wonder what they mean by OLE DB and ODBC sources

<blockquote>
 ...You should use the CommandText
 property instead of the SQL property,
 which now exists primarily for
 compatibility with earlier versions of
 Microsoft Excel. If you use both
 properties, the CommandText property’s
 value takes precedence.
 
 For OLE DB sources, the CommandType
 property describes the value of the
 CommandText property.
 
 For ODBC sources, the CommandText
 property functions exactly like the
 SQL property, and setting the property
 causes the data to be refreshed...
</blockquote>

I really appreciate your short answers.

what is the difference between OLE DB and ODBC data sources?

关系型数据库

SQL Server

数据库

我读了一篇关于pivotcache的MS Excel帮助文章，想知道OLE DB和ODBC源是什么意思 ...You应该使用CommandText属性，而不是SQL属性，现在使用SQL属性主要是为了与早期版本的Microsoft Excel兼容。如果同时使用这两个属性，则CommandText属性的值优先。对于OLE ...

问OLE DB和ODBC数据源有什么不同？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问OLE DB和ODBC数据源有什么不同？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问OLE DB和ODBC数据源有什么不同？
EN