无线 HTA 中的 DAO 与 ADO答案

【问题标题】：DAO vs ADO in HTA over wireless无线 HTA 中的 DAO 与 ADO
【发布时间】：2010-10-28 14:24:03
【问题描述】：

我编写了一个在无线网络上运行的小型（8-10 台笔记本电脑）销售点系统，作为一个 HTA，它可以读取/写入位于网络共享上的 Access MDB。
我需要使用 ADO - GetString 和用户名册不适用于 DAO。
我还需要使用 DAO——MDB 不能用 ADO 压缩。

我知道：
1）如果数据库后端不是Access MDB，我应该使用ADO。
2) 如果后端是 MDB，但我想在某个时候升级到 SQL Server，我应该使用 ADO。
3) 在 Access 应用程序或任何其他 VBA/VB 应用程序中，我应该使用 DAO，因为 ADO 必须经过 Jet OLE DB Provider 的转换层，而 DAO 更直接。
4) VBScript/JScript 允许我使用 DAO 或 ADO。

两部分问题如下：
1）在这种软件环境（HTA/脚本）下，使用ADO比使用DAO更好吗？
2) ADO 是否提供任何好处，因为 HTA 通过无线网络进行读/写？

【问题讨论】：

HTA == HTML 应用程序？
我没有使用 VBScript 进行测试，但我发现在启动应用程序时调用 JScript ActiveXObject 函数比任何其他函数产生更多的开销。 DAO 在这方面显然是赢家，因为它只需要一次调用 ActiveXObject。
我已经使用DAO实现了基本操作，并且只使用ADO for GetString。需要注意的重要一点 - 使用 DAO 执行的编辑不会立即在 ADO 连接上可见。在通过 GetString 读取之前，我需要通过 DAO 刷新 Jet 缓存。

标签： scripting ado wireless dao hta

【解决方案1】：

如果您需要 DAO 的唯一原因是压缩数据库，您可以为此使用 DAO，并为其他一切使用 ADO。您不仅限于使用 ADO 或 DAO。
使用 ADO 的最大好处是在时机成熟时更容易迁移到 SQL Server Express。您应该尽早这样做，因为 SQL Server Express 提供了 MSAccess 数据库的所有优点而没有缺点。 SQL Server Express 是免费的，它可以轻松处理您提出的系统大小。

Access 数据库在多用户环境中很容易损坏，尤其是在涉及无线网络时。如果您担心失去在 MSAccess 中工作的好处，您仍然可以使用链接表附加到 SQL Server，并以这种方式使用您的 SQL Server Express 数据库。

【讨论】：

从我看到的 SQL Server Express 来看，它不是可移植的——它需要安装在特定的机器上，不能简单地复制粘贴到不同的位置。
是否能够根据应用程序的要求移动数据库？
是的。这也是我们使用 HTA 的原因之一——因为我无法提前知道我们将使用哪个操作系统或哪个版本的 Access。（该程序主要用于以批发价出售物品，大约每月进行一次，即使使用了固定的笔记本电脑池，也很可能会借用更多的笔记本电脑。）
ADO 或 DAO 都可以正常工作，如果您愿意，可以在同一个应用程序中同时使用它们。

【解决方案2】：

您也可以使用 JRO 来压缩您的 MDB 文件。这将包含在任何最新版本的 MDAC 中，默认情况下安装在 XP 和更高版本的系统上。无需安装 Access。

回答您的具体问题：

1) 我会选择 ADO 只是因为它更新，并且相同的 API 可以用于其他类型的脚本，例如 LDAP/ActiveDirectory 访问、读取文件系统文件夹、读取 MAPI 邮件以及使用其他类型半结构化文本文件，如固定宽度文本和 CSV。它并不是特别适合 HTA 编程环境，但可能更适合您学习更广泛适用的 API。我也认为它是一个更容易使用的 API，但我是从它开始的，后来才在一些较旧的 DAO 项目中工作。

2) ADO 提供的一个可能的好处是断开连接的记录集，这可能具有优势或至少在您的无线网络设置中建议一些架构替代方案。您打开一个记录集，然后断开它，因此您仍然可以使用内存中的数据，但不必保持数据库连接处于打开状态。然后稍后您可以重新连接并更新数据库。此外，您可以通过将表作为本地 XML 或 ADTG 文件进行管理，以完全断开连接的方式工作。

【讨论】：

【解决方案3】：

您可能会强迫 DAO 使用 VBScript 工作，但这是一个奇怪的配对。一般来说，ADO 最有意义。

ADO 的另一个优点是它支持 RDS over DCOM 或 HTTP。这可用于克服通过文件共享使用的 Jet MDB 的许多限制，例如不可靠的网络和客户端可能导致的损坏。它还减少了网络上的流量，提高了性能。此外，它还提供了一个中间层，业务对象可以在其中“生存”，所有这些都可以在适用的情况下使用 COM+ 进行调解。

当然，您不再可以选择使用简单的 P2P 网络和文件共享来托管数据库。 RDS 需要一个服务器来托管进程并运行 Jet 引擎，Jet 引擎不再需要在每个客户端系统上运行。这意味着您可以使用在服务器上运行的 Jet 存储过程，卸载更多的客户端处理和网络流量。虽然不像 T-SQL 或其他替代方案那样复杂，但这种 ADO/Jet 4.0 OLE DB Provider 专有技术提供了使用 DAO 无法获得的实实在在的好处。

RDS 可以屏蔽使用断开连接记录集的大部分过程，从而简化客户端代码。它在引擎盖下使用了 ADTG，这是为此目的开发和优化的。

但是，与简单的文件共享相比，使用 RDS 需要更多的基础架构和专业知识。您不妨研究一下 SQL Server 的低端版本。

一般来说，我建议使用jetcomp.exe 实用程序通过DAO 或JRO 进行压缩和修复。它提供了许多优势。

【讨论】：

我不认为 DAO/VBScript 是这么奇怪的配对；我以前做过。
你关于 jetcomp.exe 的观点很有趣——我可以打开一个 Shell 对象并执行它。
文件共享的好处是可以将 HTA 部署到共享中并从所有对等点运行。简单的刷新 (F5) 会重新加载新更新的 HTA。没有安装；并且 HTA 在执行时没有被锁定，所以它可以被覆盖。
你是对的，这使得 HTA 非常适合创建轻量级应用程序，甚至是多用户应用程序。如果您的 HTA 也没有保持打开的连接，仅连接到查询或更新然后关闭，则可以减轻一些 MDB 损坏风险。这会增加开销和性能，但如果活动量低且网络速度快，这可能没什么大不了的 - 并且它可以防止您的 HTA 持有未提交的 MDB 的“脏”页面。

【解决方案4】：

如果您负担得起将 HTA 应用程序与 Access 一起使用而不是性能更高的平台，我会说您应该使用最简单的 API。在您的情况下，瓶颈永远不会是数据库访问的抽象。不过，DAO 真的很老了。

【讨论】：