我正在阅读有关pivotcache的MS Excel帮助文章,并想知道OLE DB和ODBC源的含义
...您应该使用CommandText属性而不是SQL属性,该属性现在主要用于与早期版本的Microsoft Excel兼容.如果同时使用这两个属性,则CommandText属性的值优先.
对于OLE DB源,CommandType属性描述CommandText属性的值.
对于ODBC源,CommandText属性的功能与SQL属性完全相同,设置属性会导致数据刷新...
我非常感谢你的简短回答.
据ADO报道:ActiveX数据对象是由Jason T. Roff出版的一本书,由O'Reilly Media于2001年出版(优秀的图表),他正是MOZILLA所说的.
(直接来自那本书的第7页)
ODBC仅提供对关系数据库的访问
OLE DB提供以下功能
无论格式或位置如何,都可以访问数据
完全访问ODBC数据源和ODBC驱动程序
因此,OLE DB似乎与基于SQL的数据源THRU ODBC驱动程序层交互.
我不是100%确定这张图片是正确的. 我不确定的两个连接是通过ADO C-api的ADO.NET,以及通过ODBC到基于SQL的数据源的OLE DB(因为在此图中作者没有通过ODBC提供OLE DB的访问,我相信是一个错误).
ODBC: - 仅适用于关系数据库(Sql Server,Oracle等)
OLE DB: - 适用于关系数据库和非关系数据库.(Oracle,Sql-Server,Excel,原始文件等)
这是我的理解(非权威):
ODBC是大多数软件供应商支持的技术无关的开放标准.OLEDB是来自COM时代的技术特定的 Microsoft API(COM是.NET之前的组件和互操作技术)
在某些时候,愿意与Microsoft数据消费者兼容的各种数据供应商(例如Oracle等)为他们的产品开发了OLEDB提供商,但在大多数情况下OLEDB仍然是仅限Microsoft的标准.现在,大多数Microsoft数据源都允许ODBC和OLEDB访问,主要是为了与旧版ODBC数据使用者兼容.此外,还存在用于ODBC的OLEDB提供程序(包装器),如果有人愿意,它允许使用OLEDB来访问ODBC数据源.
就功能而言,OLEDB实质上比ODBC更丰富,但却遭受一环到规则的所有综合症(过于通用,过于复杂,无意见).
在非Microsoft世界中,基于ODBC的数据提供者和客户端被广泛使用,而不是去任何地方.
微软泡沫OLEDB内部正在逐步淘汰原有的.NET API,无论该数据源的原生传输层是什么(例如,MS SQL Server的TDS).
ODBC和OLE DB是两种竞争数据访问技术.特别是关于SQL Server,微软已将它们作为首选未来方向推广 - 尽管在不同的时间.
ODBCODBC是一种行业范围的标准接口,用于访问类似表的数据.它主要是为数据库开发的,并在记录集合中呈现数据,每个记录集合成一组字段.每个字段都有自己的数据类型,适合其包含的数据类型.每个数据库供应商(Microsoft,Oracle,Postgres,...)都为其数据库提供ODBC驱动程序.
还有用于对象的ODBC驱动程序,虽然它们不是数据库表,但它们非常相似,因此以相同的方式访问数据非常有用.示例包括电子表格,CSV文件和列式报告.
OLE DBOLE DB是一种用于访问数据的Microsoft技术.与ODBC不同,它包含类似于表格的数据和非类似表格的数据,例如电子邮件,网页,Word文档和文件目录.但是,它是面向过程而不是面向对象的,并且被认为是开发数据源访问的一个相当困难的接口.为了解决这个问题,ADO被设计为OLE DB之上的面向对象层,并提供更简单,更高级 - 但仍然非常强大 - 的工作方式.ADO的巨大优势在于,您可以使用它来操作特定于给定类型的数据源的属性,就像您可以使用它来访问适用于所有数据源类型的属性一样容易.您不仅限于一些令人不满意的最低共同标准.
虽然所有数据库都有ODBC驱动程序,但它们并不都具有OLE DB驱动程序.但是,如果要以类似OLE DB的方式访问它们,则可以使用OLE和ODBC之间的接口.此接口称为MSDASQL(用于ODBC的Microsoft OLE DB提供程序).
SQL Server数据访问技术由于SQL Server是(1)由微软,和(2)的微软数据库平台,ODBC和OLE DB是一个天生适合它.
由于所有其他数据库平台都有ODBC接口,因此Microsoft显然必须为SQL Server提供一个.除此之外,DAO(Microsoft Access中的原始默认技术)使用ODBC作为与所有外部数据源通信的标准方式.这使得ODBC接口成为必要条件.与SQL Server 2000一起发布的SQL Server版本6 ODBC驱动程序仍然存在.已发布更新版本以处理随后发布的新数据类型,连接技术,加密,HA/DR等.截至09/07/2018,最新版本是v13.1"用于SQL Server的ODBC驱动程序",于23/03/2018发布.
这是微软自己的技术,它从2002年到2005年大力推广,以及随附的ADO层.他们显然希望它将成为首选的数据访问技术.(他们甚至使ADO成为访问Access 2002/2003中数据的默认方法.)然而,最终很明显,由于多种原因,这种情况不会发生,例如:
世界不会转换为Microsoft技术而是远离ODBC;
DAO/ODBC比ADO/OLE DB快,并且也完全集成到MS Access中,因此不会自然死亡;
微软正在开发的新技术,特别是ADO.NET,也可以直接与ODBC对话.ADO.NET也可以直接与OLE DB对话(从而使ADO处于死水状态),但它(不像ADO)完全依赖于它.
出于这些原因和其他原因,Microsoft实际上不赞成使用OLE DB作为 v11之后的SQL Server版本的数据访问技术(SQL Server 2012).在此之前的几年,他们一直在制作和更新SQL Server Native Client,它支持ODBC和OLE DB技术.然而,在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月,微软妥协并且正式弃用了OLE DB.他们宣布即将推出新驱动程序(MSOLEDBSQL),该驱动程序将具有Native Client 11的现有功能集,并且还将引入多子网故障转移和TLS 1.2支持.该驱动程序于2018年3月发布.
在非常基础的层面上,这些只是针对不同数据源(即数据库)的不同API.OLE DB更新,可以说更好.
您可以在维基百科上阅读更多内容:
OLE DB
ODBC
即,您可以使用ODBC驱动程序或OLE DB驱动程序连接到同一数据库.这些情况下数据库行为的差异是您的书所指的.
两者都是数据提供者(您的代码将用于与数据源通信的API).1998年推出的Oledb旨在取代ODBC(1992年推出)
京公网安备 11010802040832号 | 京ICP备19059560号-6 
