在Access 2007中使用ADO或DAO会更好吗？
在Access 2007中创build新数据库时，应使用ADO（ActiveX数据对象）还是DAO（数据访问对象）？
编辑：此数据库的一部分将从Excel 2007电子表格导入数据。
[为了logging，曾经是'Jet'的官方名称现在是'Access数据库引擎'。]
对于ACE（Access2007引擎.accdb格式）function，它必须是ACEDAO。
对于Jet 4.0function，它必须是ADO经典。
对于Jet 3.51function和更早版本，selectADO或DAO。 两者都有优点和缺点。 Access数据库引擎function的绝大多数对于两者都是通用的; 互相排斥的function是可争议的边缘。 也许是一种生活方式的select，但没什么大不了的。 智能编码器使用最好的:)
我已经用了很多，ADO是我的个人喜好。 它比DAO更现代化，所以架构上它是一个改进：平坦的对象模型，没有DAO的拆卸问题等。更多的属性和方法，以及引入事件（DAO没有），例如asynchronous连接和logging获取。 ADOlogging集可以断开连接，分层和制作，DAOlogging集不能。 基本上，他们把关于DAO的好东西变得更好。
DAO不是没有它的优点。 首先，你会发现比ADO的Access / Jet更多的DAO代码示例。
PS由于某种原因，喜欢DAO的人不喜欢ADO。 忽视宣传。 ADO不被弃用。 ACE有一个OLE DB提供程序，并且是当前使用64位ACE的唯一方法。 ADO.NET并没有取代ADO的经典之作，VB.NET取代了Access项目中的VBA6。
编辑：只是为了澄清，“对于Jet 4.0的function，它必须是ADO经典”，这是因为DAO 3.6只收到了一些新function的Jet 4.0的增强function。 例如，对于DECIMAL数据types，您不能指定比例/精度。 其他function从DAO完全丢失。 例如，您可以使用DAO（或ACE中的ACEDAO）在Jet 4.0中执行以下操作吗？
CREATE TABLE Test ( col1 CHAR(4) WITH COMPRESSION DEFAULT '0000' NOT NULL, CHECK (NOT EXISTS ( SELECT T1.col1 FROM Test AS T1 WHERE T1.col1 <> '0000' GROUP BY T1.col1 HAVING COUNT(*) > 1 )) );
（提示：具有表级数据完整性约束的可压缩固定宽度文本列。）否，您不能。
AFAIK ACEDAO唯一的增强function是新的ACEfunction，即他们没有回头，填补了DAO的Jet 4.0差距。 为什么他们呢？ 我们还有ADO来填补空白。 更好的是，团队花更多的时间更有成效，比如修复恼人的DECIMALsorting错误，对我来说是关于ACE的最好的事情;-)
DAO是这里推荐的技术。 ADO已经被大量贬值，现在正在被ADO.net取代。
DAO不仅是使用MS访问的原生和推荐的数据对象模型，它还在继续增强，现在有一大堆用于SharePoint的新特性。 在访问2007年，我们现在有支持SharePoint列表。 这意味着2007年新的DAO对象模型允许使用共享点列表并将其视为SQL服务器表。 这意味着您可以在SharePoint列表上使用SQL（因为甚至没有一个允许您以这种方式使用SharePoint列表的oleDB提供程序，但是现在可以通过DAO执行此操作）。 ADO中没有添加这种types的东西。 因此，从访问（dao）的angular度来看，SharePoint列表将这些SharePoint列表视为标准表。
此外，访问中的DAO也支持我们称之为复杂的数据types。 这是为了支持来自sharepoint的XML列表。 请记住访问（2010年）的下一个版本，我们将看到更多新的附加function被添加到DAO（JET现在称为ACE）。
所以DAO是正确和好的使用模式是毫无疑问的。 ADO没有得到任何改进，并被ADO.NET所取代。
所以未来属于DAO，显然这就是微软在MS访问和升级条款方面投入资金的地方。
Access 2007为其字段定义获得了多值function，这又是支持共享点的增强function的结果。 但是，这些function是JET的一部分，这些增强function可以在没有共享点的情况下使用。 他们现在是DAO的一部分。
编辑：也许我会扩大一点，并试图澄清我们在这里有这样的对立的答案，我可以向你保证，使用Access 2007时，你最好使用DAO。
如果您在select使用默认数据对象模型access 2007时看到的是工具引用，那么问题就在于它不再被称为DAO。 现在被称为ACE。
当您在Access 2007中使用DAO时您将在工具参考中注意到，该参考没有设置为DAO 3.6（该版本已被折旧，并且现在不再是MDAC下载的一部分）。 您会注意到，在ms-access中使用DAO时的新引用被称为：
Microsoft office 12.0访问数据库引擎对象库
现在上面是一个满嘴，但是上面是正确的参考访问2007年，当你要使用DAO代替ADO。
换句话说，也许我们应该称之为DAO II。
换句话说，这个数据引擎不断得到增强，并且最确切地说，这个引擎的64位版本将用于Office 2010（Office 14）。
因此，当我们在2007年访问时使用DAO的时候，问题或者困惑的中心就是要使用什么术语。这里的混淆实际上是文档甚至工具 – >引用不称之为DAO。
在访问2007年的一天结束时，如果您计划使用DAO，则意味着您设置了上述引用，并且不要设置对DAO 3.6的引用。 无论如何，当ADO被贬值时，开始使用ADO是绝对没有意义的，而新的DAO对象访问模型继续被微软增强和投入。
我希望这有助于澄清这里的混乱。 虽然DAO / JET这是贬值，新版本访问2007年是基于相同的代码基础，除了它不断得到增强。 所以访问中的新数据引擎可以被认为是新的DAO对象模型。
目前，我在这个问题上的NDA，但我可以肯定地告诉你，对于下一个版本的办公室（2010年），我们将再次看到一大堆的增强。
因此，Access开发人员几乎一致认为，在开发访问应用程序和使用本地数据引擎时，这里的首选是使用DAO对象模型（但是请记住，我们不再调用它，我们称之为ACE）。
问题的答案取决于你在做什么。 如果您使用Access来处理ADO界面更通用的格式的数据，请使用ADO。 如果您正在使用Jet数据，或使用Jet数据库引擎与另一个数据库引擎（通过ODBC）一起使用，那么DAO是正确的select。
但是这个答案假设你正在从Access工作。 如果你在其他编程环境下工作，答案可能会完全不同。
这取决于你的需求。 预计这两种工具都不会很快消失。
如果你没有ADO或DAO的经验，你会发现DAO要容易得多。 所以，除非你需要ADO，否则使用DAO。
您添加了这个关键项目：“我试图从外部来源的数据到Access数据库。” 这种连接可能需要ADO。
ADO是目前推荐的访问方法。 我认为DAO已经被弃用了很多年了。
看起来像自Access 2000以来 – 根据这个环节 ，
过时的数据访问技术列表 – http://msdn.microsoft.com/en-us/library/ms810810.aspx#mdac技术路线图old_topic9
引用了上面2008年12月修订的文章 – “数据访问对象（DAO）”：DAO提供了访问JET（Access）数据库的途径，这个API可以从Microsoft Visual Basic，Microsoft Visual C ++和脚本语言中使用。包含在Microsoft Office 2000和Office XP中，DAO 3.6是该技术的最终版本，在64位Windows操作系统上不可用。
与ADO相比，DAO在性能方面performance不佳。 没有比较。
道歉，这是一个答案，当它应该是一个评论（我没有代表），但我想澄清一个错误的声称，DAO / ACEDAO不支持Jet 4.0logginglocking。 它的确如此，这是默认的行为，不pipe某些MS文章声称如何。
问题是这可能会在使用DAO编辑/更新时引入巨大的膨胀（极其分散的DB文件），并且您无法在DAO / ACEDAO中将其closures。
如果您遇到此问题，可以通过首先使用正确的Jet OLEDB：数据库locking模式设置通过OLEDB连接打开数据库将其closures，这将允许您将数据库设置为页级locking。 这个属性将被后续的连接，DAO或其他方式所尊重，所以你可以使用DAO进行快速更新等。
与执行SQL语句相比，这将允许DAO恢复到通常的8X性能。
这里有几个指向这个问题的链接：
ACEDAO是否支持行级locking？
http://www.access-programmers.co.uk/forums/showthread.php?t=47040
MS知识库文章，包括与ADO设置locking模式的代码，然后使用该数据库上的DAO – http://support.microsoft.com/?id=306435
