什么时候应该使用OLE-DB，ADO或ODBC

要在访问数据时判断出应该使用哪一种技术，这并不容易。可能需要公用实用程序来处理多个数据库类型；部分数据可能出现在本地硬盘驱动器上，部分在网络上，还有一部分在主机上。甚至客户安装在设备上的产品也会使这种选择更加困难。例如，你所期待的ODBC支持级别也许依赖于所安装的MicrosoftOffice的版本，因为这个产品不提供ODBC支持。你还会发现，ADO类提供的对象和方法要比ODBC类多。ADO可以提供程序中绝对必须具有的一些特性棗例如，你会发现OLE-DB和ADO两者都支持DFX_Currency，但在ODBC中没有对应的功能棗但你要想掌握它们也必须付出一定的努力。
注 使用ADO而不是ODBC的一个原因是，ADO提供的对象和方法比ODBC多。
选择OLE-DB或ODBC时，有几条一般的规则。因为ADO实际上只是OLE-DB的包装，所以这些规则也适用于它。下面提供一些基本的原则，可以用来帮助你决定选择OLE-DB还是ODBC。
非OLE环境 如果要访问支持ODBC的数据库，而该数据库又在不支持OLE的服务器上，那么ODBC是最好的选择。
非SQL环境 ODBC在处理SQL时非常出众。处理非SQL数据库时，OLE-DB则具有非常明显的优势。
OLE环境 对支持OLE的服务器来说，选择OLE-DB还是ODBC也许是希望各半。如果有ODBC驱动程序可供利用，那么使用ODBC是一个好主意；否则，就只有选择OLE-DB了。
所需的互操作性 如果需要可互操作的数据库部件，那么只有选择OLE-DB。
其它的问题往往是复合问题，或者至少是失去了可以用来区别这两种技术的方便的规则。例如，有一些特征是ADO和ODBC所共有的。其中一个特征是，Visual C++允许你直接访问任一种技术。这意味着，可以完全访问ADO和ODBC都提供的每一个特征（是的，这确实不错，但也有缺陷，因为谈到访问，不能说一种技术明显地优于另一种技术）。
如果做了错误的决定，一些熟悉的技术实际上会帮助你把应用程序从ODBC转移到ADO，或反方向转移。两种技术都依靠数据库对象来管理基础的DBMS，而记录集对象则包含针对DBMS的查询结果。另外，ODBC和ADO都以相似的成员来使用数据库和记录集对象。即使要对类和成员名称做一些更改，你仍会发现，ODBC和ADO程序设计的代码非常相似。
ODBC和ADO都依靠外部驱动程序来完成任务。但是，用ADO还可以从Microsoft Jet引擎获得额外的帮助。这个额外的支持是如何使程序设计更加容易的呢？考虑一下，要在哪里执行两个依赖不同引擎的数据库的外部连接。在ODBC下，必须人工执行全部所需的设置。使用ADO意味着，Microsoft Jet引擎会为你执行这些设置。可惜的是，让ADO做这个工作意味着会失去控制级别和一些灵活性，而这正是你从一开始就想用C++获取数据的原因。
注 ODBC和ADO具有相似的特征，如记录集和数据库对象，尽管MFC利用这些对象的方式完全不同。
有一个地方绝对不能使用ADO。如果要访问16位数据，就不能用ADO。不管你怎么想，都必须用ODBC。然而，几乎没有人还在使用16位数据库了。大多数的新工程都会使用32位接口，这意味着会有一个选择。老的工程已经有了嵌入代码的数据访问方法，所以你也实在没有必要在这里做决定。
ODBC的一点不足是，不能像以前使用ADO那样跟踪事务。以Microsoft Jet引擎使用ADO时，应该得到事务的工作区级的支持。ODBC只提供数据库级的事务支持，这就是说，可以从几个不同的工作区跟踪事务（这使得调试非常困难，还可能导致其它类型的问题）。
注释 处理ODBC数据库时，ADO提供数据库级的支持；这和ODBC提供的支持层次是相同的。除非你使用Microsoft Jet引擎，否则得不到工作区级事务支持的好处。