我正在阅读有关数据透视缓存的MS Excel帮助文章，想知道它们对OLE DB和ODBC源的含义
...您应该使用CommandText属性而不是SQL属性，该属性现在主要是为了与Microsoft Excel的早期版本兼容。如果同时使用两个属性，则CommandText属性的值优先。
对于OLE DB源，CommandType属性描述CommandText属性的值。
对于ODBC源，CommandText属性的功能与SQL属性完全相同，并且设置该属性将导致刷新数据...
非常感谢您的简短回答。
Answers:
根据ADO：ActiveX Data Objects（Jason T. Roff的一本书，由O'Reilly Media于2001年出版）（此处的图表非常出色），他准确地说出了MOZILLA所说的话。
（直接来自该书的第7页）
- ODBC仅提供对关系数据库的访问
- OLE DB提供以下功能
- 访问数据，无论其格式或位置如何
- 完全访问ODBC数据源和ODBC驱动程序
因此，似乎OLE DB通过ODBC驱动程序层与基于SQL的数据源进行交互。
我不是100％确定此图片正确。 我不确定的两个连接分别是ADO.NET和ADO C-api，以及OLE DB和ODBC以及基于ODBC的基于SQL的数据源（因为在此图中，作者并未通过ODBC来访问OLE DB，我相信是一个错误）。
System.Data.SqlClient仅使用本机代码来处理网络上的TCP /命名管道/等传输，从而以托管代码处理TDS协议。对于没有自己的托管提供程序的数据库，可以使用System.Data.OleDbOLE DB或System.Data.OdbcODBC的包装，但是不建议这样做。
ODBC：-仅适用于关系数据库（Sql Server，Oracle等）
OLE DB：-对于关系数据库和非关系数据库。（Oracle，Sql-Server，Excel，原始文件等）
Open Database Connectivity (ODBC) is Microsoft's strategic interface for accessing data in a heterogeneous environment of relational and non- relational database management systems. support.microsoft.com/en-us/kb/110093
这是我的理解（非权威）：
ODBC是大多数软件供应商都支持的与技术无关的开放标准。OLEDB是COM时代的技术特定的Microsoft API（COM是.NET之前的组件和互操作性技术）
在某些时候，愿意与Microsoft数据消费者兼容的各种数据源供应商（例如Oracle等）已经为其产品开发了OLEDB提供程序，但在大多数情况下，OLEDB仍然是仅Microsoft的标准。现在，大多数Microsoft数据源都允许ODBC和OLEDB访问，主要是为了与旧的ODBC数据使用者兼容。此外，还存在用于ODBC的OLEDB提供程序（包装程序），如果愿意，它允许使用OLEDB访问ODBC数据源。
就功能而言，OLEDB比ODBC丰富得多，但饱受一环到规则的所有综合症的困扰（过于通用，过于复杂，未接受过修饰）。
在非Microsoft世界中，基于ODBC的数据提供程序和客户端得到了广泛使用，并且无处不在。
在Microsoft泡沫内部，正在逐步淘汰OLEDB，而倾向于在该数据源的本机传输层（例如MS SQL Server的TDS）之上构建本机.NET API。
ODBC和OLE DB是两种竞争的数据访问技术。尤其是在SQL Server方面，Microsoft已将二者都作为首选的未来发展方向进行了推广-尽管时间不同。
ODBC是用于访问类表数据的行业范围内的标准接口。它最初是为数据库开发的，并以记录的集合形式显示数据，每个记录都分组为一个字段集合。每个字段都有适合其包含的数据类型的自己的数据类型。每个数据库供应商（Microsoft，Oracle，Postgres等）都为其数据库提供了ODBC驱动程序。
还有一些对象的ODBC驱动程序，尽管它们不是数据库表，但它们非常相似，因此以相同的方式访问数据很有用。例如电子表格，CSV文件和列式报告。
OLE DB是用于访问数据的Microsoft技术。与ODBC不同，它既包含表数据又包含非表数据，例如电子邮件，网页，Word文档和文件目录。但是，它是面向过程而不是面向对象的，并且被认为是用于开发对数据源的访问的相当困难的接口。为了克服这个问题，ADO被设计为OLE DB之上的面向对象层，并提供了一种更简单，更高级（尽管仍然非常强大）的工作方式。ADO的巨大优势在于，您可以使用它来操纵特定于给定类型的数据源的属性，就像使用它来访问适用于所有数据源类型的那些属性一样容易。您并不受限于某些令人满意的最低公分母。
虽然所有数据库都具有ODBC驱动程序，但它们并不都具有OLE DB驱动程序。但是，如果要以类似OLE DB的方式访问它们，则可以使用OLE和ODBC之间的接口。此接口称为MSDASQL（用于ODBC的Microsoft OLE DB提供程序）。
由于SQL Server是（1）由Microsoft制造，并且（2）是Microsoft数据库平台，因此ODBC和OLE DB都是很适合的。
由于所有其他数据库平台都具有ODBC接口，因此微软显然必须为SQL Server提供一个。除此之外，DAO是Microsoft Access中的原始默认技术，它使用ODBC作为与所有外部数据源进行通信的标准方式。这使ODBC接口成为必要条件。与SQL Server 2000一起发布的用于SQL Server的版本6 ODBC驱动程序仍然存在。已发布更新版本，以处理后续版本中出现的新数据类型，连接技术，加密，HA / DR等。截至2018年7月7日，最新版本为v13.1``SQL Server的ODBC驱动程序''，于2018年3月23日发行。
这是Microsoft自己的技术，大约在2002年至2005年间，微软一直在大力推动这项技术以及其附带的ADO层。他们显然希望它将成为首选的数据访问技术。（他们甚至使ADO成为Access 2002/2003中访问数据的默认方法。）但是，最终由于多种原因，这种情况最终不会发生，例如：
由于这些原因和其他原因，Microsoft实际上不赞成将OLE DB作为v11（SQL Server 2012）之后的SQL Server版本的数据访问技术。在此之前的几年中，他们一直在生产和更新支持ODBC和OLE DB技术的SQL Server Native Client。但是，在2012年末，他们宣布将与ODBC配合使用，以在SQL Server中进行本机关系数据访问，并鼓励其他所有人也这样做。他们进一步指出，v11 / SQL Server 2012之后的SQL Server版本将主动不支持OLE DB！
这一宣布激起了抗议浪潮。人们不知所措，为什么MS突然弃用了他们花了多年才致力于的一项技术。此外，SSAS / SSRS和SSIS是由MS编写的与SQL Server紧密相关的应用程序，完全或部分依赖于OLE DB。另一个抱怨是OLE DB具有某些理想的功能，似乎无法移植回ODBC –毕竟，OLE DB有很多优点。
2017年10月，Microsoft撤销了OLE DB并正式弃用了OLE DB。他们宣布即将推出新驱动程序（MSOLEDBSQL），该驱动程序将具有Native Client 11的现有功能集，并将引入多子网故障转移和TLS 1.2支持。该驱动程序于2018年3月发布。
•2011年8月：Microsoft弃用OLE DB（Microsoft正在与ODBC进行本机关系数据访问）
•2017年10月：Microsoft弃用OLE DB（宣布SQL Server的OLE DB驱动程序的新版本）
我不确定所有细节，但我的理解是OLE DB和ODBC是两个API，可用于连接到各种类型的数据库，而不必处理每个数据库的所有特定于实现的细节。根据OLE DB上的Wikipedia文章，OLE DB是Microsoft到ODBC的继承者，并且提供了一些您可能无法使用ODBC进行的功能，例如访问电子表格作为数据库源。
在Microsoft网站上，它表明本机OLEDB提供程序直接应用于SQL Server，而另一个OLEDB提供程序称为OLEDB提供程序，用于ODBC访问其他数据库，例如Sysbase，DB2等。OLEDB提供程序下有不同类型的组件。有关更多信息，请参见MSDN上的分布式查询。