在两种相关技术的背景下,“本机”是什么意思?

也许我错了,但我总是这样理解:

• MS Jet数据库引擎完全是一个数据库引擎(是否动力不足)
• 它与外部世界的“本机”接口是一种SQL方言

鉴于:

• DAO是Microsoft的数据库抽象层之一,专为在诸如VBA或Windows脚本之类的COM环境中使用而设计。
• 它是使用Access开发的(可以将其视为MS Jet的用户界面/报告工具,因为MS Jet可以不使用MS Access而存在),并且与MS Jet和MS Access紧密捆绑在一起,尽管如此,它与ADO所处的类别相同。

在我看来,这个问题并不是真的诚恳地发表的——它完全是针对我和我对你的评论所作的评论。我已经回答了其他地方的所有问题,但为了清楚起见,让我概述一下喷气式飞机的历史。

喷气式飞机是在90年代初与Access一起引进的。在第1版和第2版之间,微软收购了FoxPro,并将其“Rushmore”技术并入了Jet。在这个时间框架的某个地方,MS开发了DAO作为到Jet的接口层。我不知道DAO曾经存在过一个事实,除了一个数据接口层,它使用Jet进行所有数据访问,但这就是它在我看来的样子。Jet是一个不错的选择,因为有了ODBC和可安装的ISAM,它可以使任何当时常用的数据库格式在应用程序中的外观和行为与本机Jet数据的外观和行为相同。早在那时,桌面数据库市场就被数据库及其变体和悖论所主导。这些都是桌面数据库引擎,而不是服务器数据库。对服务器数据库的访问通常是通过ODBC进行的,但对桌面数据库应用程序开发人员来说并不是那么重要。虽然有时会出错(这就是为什么在Jet中引入ODBCDirect的原因,它将绕过Jet数据处理引擎的某些方面),但Jet能够很好地连接到ODBC数据源并有效地利用它们。

现在,随着access/jet/dao的兴起,Visual Basic成为了通用Windows应用程序开发的热门产品,在Web蓬勃发展之前,VB是世界上使用最广泛的编程语言。DAO和Jet为VB开发人员提供了到各种数据存储的接口,并且VB开发工具与它们很好地集成在一起。因此,在ODBC之后,DAO成为MS的关键数据接口层,利用Jet引擎处理各种数据。

当然,这有它的问题,而且也非常局限于jet/dao(和vb)都是面向桌面的工具。到90年代中后期,微软正试图从桌面软件、桌面操作系统和开发工具的供应商扩展到企业软件供应商。因此,MS需要开发更健壮的数据接口,比如数据库服务器的ODBC,但是要具备较新的服务器数据库所提供的所有现代功能。OLEDB就是答案,ADO是OLEDB上的接口层(就像DAO是Jet上的接口层一样)。虽然DAO的目标是通过Jet数据库引擎提供对大量数据存储的访问,但是OLEDB是一个更中立的数据接口层,如ODBC,一个数据库抽象层,而ADO是到中立数据接口层的接口。

在“本机”DDL的问题上,事实上在Jet4之前,对SQL DDL的支持非常差。也就是说,Jet的一些特性不能通过SQL DDL控制。相反,您必须使用DAO来控制这些特性。虽然Jet数据库引擎程序员当然在DAO示例旁边包含了DDL示例,但是DAO示例能够做得更多,因为Jet DDL SQL从未支持Jet数据库的所有功能。

看起来如此混乱的崩溃是由于微软内部的政治。到1999年,微软推出了Access2000(新版本的Jet,4.0),微软想让DAO退出,转而支持ADO。MS使ADO成为Access中的默认数据接口层,即使使用ADO没有意义(即,您的数据存储是Jet)。作为这项工作的一部分,微软并没有完全更新DAO,将对Jet4所有新功能的支持纳入其中——相反,他们将自己在这方面的努力投入到ADO中。结果是,Jet的本地数据接口层DAO缺少对数据库中立接口层ADO提供的Jet功能的支持。在我看来,这是微软的一种特殊形式。微软故意不更新jet的本机接口层,以迫使您使用非本机接口。因此,您必须使用ADO->OLEDB->Jet,而不是DAO->Jet,甚至用于Jet数据库引擎的某些本机方面(例如字段的某些数据类型)。

微软的目标是完全消灭DAO,实际上是消灭喷气机本身。他们希望客户迁移到SQL Server。

但是发生了很多事情。首先,基于COM的ADO不能很好地适应.NET,因此,经典的基于COM的ADO最终被放弃,ADO.NET被创建来取代它。ADO和ADO.NET之间的相似性是非常肤浅的,基于完全不同的数据交互模型,ADO.NET几乎完全围绕断开连接的数据思想进行设计,而ADO没有(尽管它确实支持某些类型的断开连接的数据访问)。

随着ADO走出窗口,微软的产品线中间出现了一个漏洞。经典的VB开发人员或Access开发人员不会在.NET中看到太多好处,因为整个数据访问模型不适合。因此,到2002年的Access发布时,MS已经改变了方向,并将DAO放回原来的位置,作为Jet数据的默认数据接口层(而且所有其他数据存储都可以通过VIA工作,例如,ODBC等)。不幸的是,虽然微软现在不赞成ADO与Jet一起使用,但他们没有选择修复与之配套的DAO的残缺版本。也许他们没有这样做,因为此时已经决定将现有的Jet4分叉到Access开发组拥有的数据库引擎中。这最终成为了Ace,无论出于何种目的,都是Jet4.5。发布了DAO的新版本(虽然有点伪装,其用户友好名称是“Microsoft Office 12.0 Access数据库引擎对象库”,而DLL名称现在是acedao.dll)。我不知道DAO 3.6(Jet4版本)中缺少的特性被添加到DAO的ACE版本中的程度。我不知道,因为我不知道 需要 这些功能中的任何一个都不知道它们是什么。

在任何情况下,在这一点上,Jet(我们已经承诺Jet4是它的最终版本)和它本身的数据接口层(DAO,我们也已经承诺了DAO已经死了)正在进行开发。这项正在进行的开发现在在微软的Access应用程序组中(与以前维护Jet4的Windows不同)。

Microsoft在Access中添加了兼容模式以使用他们所称的ansi-92 sql模式。这应该允许您编写与SQL Server的SQL方言“兼容”的SQL。嗯,它支持一些东西(您可以使用SQL Server通配符,并将()用于派生表,而不是jet的scredy[]。作为别名),但不太接近TSQL。但是在访问之外,使用这个“ansi-92”SQL模式的唯一方法是使用ado连接到jet。DAO本身仍然使用Jet的SQL旧方言。这表明Jet本身不支持这种模式,但它是由Jet上面的层提供的。