虽然不赞成，DAO仍然用于从Excel自动化的Access数据库？
我正在试图把我的头围绕着它。 我查了其他的问题，似乎没有什么太相似的。
Office 2013开发中心包含丰富的DAO示例，并指出使用Access文件（不需要Access窗口）的最简单方法之一，但是DAO是已弃用的技术。 （ https://msdn.microsoft.com/en-us/library/office/ff834801.aspx ）
我正在尝试编写一个Excel加载项（最终结束点），它将以.accdb格式对Access赋值赋值。
我不能只使用ADODB来执行SQL查询来提取数据，除非SQL也可以执行以下操作：
- 检查指定的报告是否有指定的标题
- 检查是否存在指定的表，查询，表单和报告
- 检查表中的特定字段是否存在
- 检查是否已将特定字段设置为主键
我还需要检查表中是否存在某些值，但是我可以使用SQL来解决这些值。
那么我应该使用DAO还是坚持使用ADODB？ 请记住，我正在使用Excel，而不是在Access VBA中编程。
使用Excel表格最简单的方法是在Access中手动或通过VBA中的TransferSpreadsheet函数链接它们。 如果您在Excel中使用文件名和选项卡名称的通用命名标准，则不必重新链接，而是可以replaceExcel文件，Access链接将读取新文件，除非布局已更改。
一旦链接，你可以使用查询的示例工具来编写你的查询也可以写入代码（即embedded在VBA [老学校，而不是一个最佳实践]或保存在Access表中，然后查找和分配到与CurrentDb.Execute strSQL，dbFailOnError命令一起使用的variables。
我build议手动链接第一轮，所以你可以手动定义单独的列types与让Access搞砸了。
如果您不能使用通用名称并且必须通过浏览对话框select文件，则可以通过Google获取文件浏览function，以便以编程方式链接文件。 （或者你可以重新命名为一个通用的名字，甚至更好）
所以DAO与ADODB从Access的angular度来看是没有意义的。 过去4年来，我用70,000多行代码和几十个Excel源文件支持了50个数据库，而且从来没有思考过这个问题。
微软最初弃用了DAO，转而采用ADO，但最近又将DAO重新命名为Microsoft Access Engine（ACE），并将其推广为自动化支持的环境（VBA，WSH等）的首选数据访问技术。
一般来说，在你的情况下，我不认为你使用哪一个差别太大。 我build议你通读一下 。
我不认为有可能通过SQL读取表/查询/字段信息。 但是，可以使用DAO.TableDefs和DAO.QueryDefs集合或ADO.OpenSchema方法来完成此操作。
RE：forms / reports – 我不知道是否可以通过DAO或ADO读取表单/报表信息，即使没有SQL，因为它实际上是UI对象的一部分，而不是数据。 除非我们正在讨论读/parsing系统表。 您可能必须在隐藏的Access实例中打开数据库，并以此方式读取表单/报告。