有问题的场景与备受诟病的Microsoft Jet 数据库引擎有关。断言是数据访问对象(DAO) 数据访问技术是 Jet 的“原生”，这意味着通过 DAO 模型创建对象优于通过在Microsoft Access中执行的 SQL 代码执行相同操作用户界面。
此外，有人断言，如果您无法通过 DAO 创建某些东西，那么根据定义，它不是 Jet 的“原生”。
对我来说，这个“原生”的定义似乎放错了地方。有许多 Jet 对象，出于历史和 Microsoft 政治原因，在 DAO 中省略或仅部分实现（CHECK约束、固定宽度数据类型、DECIMAL数据类型、可压缩数据类型等），但包含在 Jet 的 SQL 中数据定义语言(DDL)。直觉告诉我，Jet SQL DDL 应该被认为是 Jet 引擎的“原生”。
所以我的问题是：为什么一项看似外部的技术 (DAO) 会被视为“本地”，而另一项看似内部的技术 (SQL DDL) 会被视为“非本地”？我是否应该为某些东西是“本地的”还是其他东西而烦恼？
在我看来，这个问题并不是真诚地发布的——它完全是针对我和我为回应你的评论而做出的评论。我已经在其他地方回答了所有问题，但为了清楚起见，让我概述一下 Jet 的历史。
Jet 在 90 年代初与 Access 一起推出。在版本 1 和 2 之间，MS 收购了 Foxpro 并将其“Rushmore”技术整合到 Jet 中。在这个时间框架的某个地方，MS 开发了 DAO 作为 Jet 的接口层。我不知道 DAO 曾经作为一个数据接口层以外的任何东西存在过，它使用 Jet 进行所有数据访问，但在我看来就是这样。Jet 是一个相当不错的选择，因为使用 ODBC 和可安装的 ISAM，它可以使几乎任何当时常见的数据库格式在您的应用程序中的外观和行为方式与原生 Jet 数据的外观和行为方式相同。那时，桌面数据库市场由 dBase 及其变体和 Paradox 主导。这些都是桌面数据库引擎，而不是服务器数据库。访问服务器数据库通常是通过 ODBC，但当时对桌面数据库应用程序开发人员来说并不是那么重要。Jet 很好地连接到 ODBC 数据源并非常有效地利用它们，尽管它有时会出错（这就是为什么将 ODBCDirect 引入 Jet 的原因，它会绕过 Jet 数据处理引擎的某些方面）。
现在，随着 Access/Jet/DAO 的兴起，Visual Basic 是通用 Windows 应用程序开发的热门产品，在 Web 蓬勃发展之前，VB 是世界上使用最广泛的编程语言。DAO 和 Jet 为 VB 开发人员提供了各种数据存储的接口，并且 VB 开发工具与他们很好地集成在一起。因此，在 ODBC 之后，DAO 成为 MS 的关键数据接口层，利用 Jet 引擎处理各种数据。
当然，这有其问题，并且由于 Jet/DAO（和 VB）都是面向桌面的工具而受到很大限制。到 90 年代中后期，MS 试图从桌面软件、桌面操作系统和开发工具的提供商扩展到企业软件提供商。因此，MS 需要开发更强大的数据接口，例如用于数据库服务器的 ODBC，但要具有较新的服务器数据库提供的所有现代功能。OLEDB 是解决此问题的答案，ADO 作为 OLEDB 顶部的界面层（就像 DAO 是 Jet 顶部的界面层一样）。虽然 DAO 的目标是通过 Jet 数据库引擎提供对大量数据存储的访问，但 OLEDB 是一个更中性的数据接口层，如 ODBC，一个数据库抽象层，而 ADO 是该中性数据接口层的接口。
关于“原生”DDL 的问题，事实是在 Jet 4 之前对 SQL DDL 的支持很差。也就是说，Jet 的某些功能无法通过 SQL DDL 控制。相反，您必须使用 DAO 来控制这些功能。虽然 Jet 数据库引擎程序员当然包括 DDL 示例和 DAO 示例，但 DAO 示例能够做的更多，因为 Jet DDL SQL 从不支持 Jet 数据库的所有功能。
由于 MS 内部政治，似乎如此令人困惑的故障发生了。到 1999 年，当 MS 推出 Access 2000（带有新版本的 Jet，4.0）时，MS 希望退出 DAO 以支持 ADO。MS 使 ADO 成为 Access 中的默认数据接口层，即使使用 ADO 没有意义（即，您的数据存储是 Jet）。作为这项工作的一部分，MS 没有完全更新 DAO 以包含对 Jet 4 的所有新功能的支持——相反，他们将这方面的工作投入到 ADO 中。结果是 Jet 的本机数据接口层 DAO 缺乏对数据库中立接口层 ADO 提供的 Jet 功能的支持。在我看来，这是微软的一种特殊形式的混蛋。MS 故意不更新 Jet' s 本机接口层，以强制您使用非本机接口。因此，您必须使用 ADO->OLEDB->Jet 来代替 DAO->Jet，甚至对于 Jet 数据库引擎的某些本机方面（例如字段的某些数据类型）。
微软的目标是彻底消灭 DAO，实际上是消灭 Jet 本身。他们希望客户迁移到 SQL Server。
但是发生了很多事情。一方面，基于 COM 的 ADO 不能很好地适应 .NET，因此，经典的基于 COM 的 ADO 最终被放弃，并创建了 ADO.NET 来取而代之。ADO 和 ADO.NET 之间的相似之处非常肤浅，并且基于完全不同的数据交互模型，ADO.NET 几乎完全围绕断开数据的概念设计，而 ADO 不是（尽管它确实支持某些类型的断开数据）数据访问）。
随着 ADO 的退出，微软的产品线中间出现了一个漏洞。经典的 VB 开发人员或 Access 开发人员不会在 .NET 中看到太多好处，因为整个数据访问模型不适合。因此，通过 Access 2002 的发布，MS 改变了方向，将 DAO 重新作为 Jet 数据的默认数据接口层（以及 Jet 可以使用的所有其他数据存储，例如 ODBC 等）。不幸的是，虽然 MS 现在不赞成将 ADO 与 Jet 一起使用，但他们并没有选择修复与它一起使用的 DAO 的残缺版本。也许他们没有这样做，因为此时已经决定将现有的 Jet 4 分叉到 Access 开发组拥有的数据库引擎中。这最终成为了 ACE，从所有意图和目的来看，它都是 Jet 4.5。发布了一个新版本的 DAO（虽然它的用户友好名称是“Microsoft Office 12.0 Access 数据库引擎对象库”，而 DLL 名称现在是 ACEDAO.DLL）。我不知道DAO 3.6（Jet 4 版本）中缺少的功能已添加到DAO 的ACE 版本的程度。我不知道，因为我不需要这些功能中的任何一个，所以甚至不知道它们是什么。
无论如何，在这一点上，Jet（我们曾被承诺 Jet 4 已结束）和它的原生数据接口层（DAO，我们也曾被承诺已死）正在进行开发. 这种持续的开发现在在 Microsoft 的 Access 应用程序组中进行（与以前维护 Jet 4 的 Windows 不同）。
Microsoft 在 Access 中添加了兼容模式，以使用他们所谓的 ANSI-92 SQL 模式。这应该允许您编写与 SQL Server 的 SQL 方言“兼容”的 SQL。好吧，它支持一些东西（您可以使用 SQL Server 通配符并使用 () 来表示派生表，而不是 Jet 的螺旋 []。作为别名），但不是很接近 TSQL。但在 Access 之外，使用这种“ANSI-92”SQL 模式的唯一方法是使用 ADO 连接到 Jet。DAO 本身仍然使用 Jet 的旧 SQL 方言。这表明 Jet 本身并没有提供对这种模式的支持，而是由 Jet 之上的层提供的。
也许我在这里错了，但我一直是这样理解的：
然而：