OLE DB和ODBC数据源有什么区别？
我正在阅读关于pivotcache的MS Excel帮助文章，并想知道它们是什么意思的OLE DB和ODBC源
…您应该使用CommandText属性而不是SQL属性，该属性现在主要用于与早期版本的Microsoft Excel兼容。 如果您使用这两个属性，CommandText属性的值优先。
对于OLE DB源 ，CommandType属性描述CommandText属性的值。
对于ODBC源 ，CommandText属性的function与SQL属性完全相同，并且设置属性会导致数据刷新…
我真的很感激你的简短答案。
根据ADO：ActiveX Data Objects ，O'Reilly Media于2001年出版的Jason T. Roff的一本书 （这里出色的图），他正是说MOZILLA所说的。
（直接从该书的第7页）
- ODBC仅提供对关系数据库的访问
- OLE DB提供以下function
- 无论其格式或位置如何访问数据
- 完全访问ODBC数据源和ODBC驱动程序
所以看起来，OLE DB与基于SQL的数据源通过ODBC驱动程序层进行交互。
我不是100％确定这张图片是正确的。 我不确定的两个连接是ADO.NET通过ADO C-API和OLE DB通过ODBC到基于SQL的数据源（因为在这个图中 ，作者不会通过ODBC来让OLE DB访问，我相信是一个错误）。
ODBC： – 仅用于关系数据库（Sql Server，Oracle等）
OLE DB： – 用于关系数据库和非关系数据库。 （Oracle，Sql-Server，Excel，原始文件等）
这是我的理解（非权威）：
ODBC是大多数软件供应商支持的与技术无关的开放标准。 OLEDB是一个来自COM时代的技术特定的微软API（COM是.NET之前的组件和互操作技术）
在某些时候，愿意与微软数据消费者兼容的各种数据供应商（例如Oracle等）为其产品开发OLEDB提供商，但大部分情况下，OLEDB仍然是微软唯一的标准。 现在，大多数Microsoft数据源都允许ODBC和OLEDB访问，主要是为了兼容传统的ODBC数据使用者。 此外，还有ODBC的OLEDB提供程序（包装器），允许使用OLEDB访问ODBC数据源（如果有的话）。
就function而言，OLEDB实质上比ODBC更丰富，但却遭受了单一戒指到全部的综合征（过度泛化，过度复杂化，非自发性）的困扰。
在非微软世界中，基于ODBC的数据提供者和客户端被广泛使用，而且不会去任何地方。
在微软的泡沫内部，OLEDB正逐渐被淘汰，而不论本地数据源的传输层是什么（例如MS SQL Server的TDS），都build立在本地.NET API之上。
在一个非常基本的层面上，这些对于不同的数据源（即数据库）来说只是不同的API。 OLE DB更新，可以说更好。
您可以在维基百科上阅读更多内容：
- OLE DB
- ODBC
即您可以使用ODBC驱动程序或OLE DB驱动程序连接到相同的数据库。 在这些情况下数据库行为的差异就是你的书所指的。
两者都是数据提供者（您的代码将用于与数据源通信的API）。 1998年推出的Oledb是为了取代ODBC（1992年推出）
我不确定所有的细节，但我的理解是，OLE DB和ODBC是两个API，可以连接到各种types的数据库，而不必处理每个实现的具体细节。 根据维基百科关于OLE DB的文章 ，OLE DB是Microsoft的ODBC的inheritance者，并提供了一些您可能无法使用ODBC的function，例如将电子表格作为数据库源访问。
在Microsoft网站上，它显示本地OLEDB提供程序直接应用于SQL服务器，另一个OLEDB提供程序称为OLEDB提供程序用于ODBC访问其他数据库，如Sysbase，DB2等。在OLEDB提供程序下有不同种类的组件。 有关更多信息，请参阅MSDN上的分布式查询 。
ODBC仅适用于关系数据库，它不能与非关系数据库（如Ms Excel文件）一起使用。 Olebd可以做任何事情。
要知道为什么M $事实OLEDB，你不能比较OLEDB和ODBC。 相反，您应该将OLEDB与DAO，RDO或ADO进行比较。 后者在很大程度上依赖于SQL。 但是，OLEDB依赖于COM。 但是ODBC已经有很多年了，所以有一个OLEDB-ODBC桥梁来弥补这一点。 当M $发明OLEDB时，我认为有一个很大的图像。
