我编写了一个在无线网络上运行的小型（8-10 台笔记本电脑）销售点系统，作为一个 HTA，它可以读取/写入位于网络共享上的 Access MDB。
我需要使用 ADO - GetString 并且用户名册不适用于 DAO。
我还需要使用 DAO——不能用 ADO 压缩 MDB。
我知道：
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 通过无线网络进行读/写？
如果您需要 DAO 的唯一原因是压缩数据库，那么您可以为此使用 DAO，并为其他一切使用 ADO。您不仅限于使用 ADO 或 DAO。
使用 ADO 的最大好处是在时机成熟时更容易迁移到 SQL Server Express。您应该尽早这样做，因为 SQL Server Express 提供了 MSAccess 数据库的所有优点而没有缺点。SQL Server Express 是免费的，它可以轻松处理您提出的系统大小。
Access 数据库在多用户环境中很容易损坏，尤其是在涉及无线网络时。如果您担心失去在 MSAccess 中工作的好处，您仍然可以使用链接表附加到 SQL Server，并以这种方式使用您的 SQL Server Express 数据库。
您还可以使用 JRO 压缩您的 MDB 文件。这将包含在任何最新版本的 MDAC 中，默认情况下安装在 XP 和更高版本的系统上。无需安装 Access。
要回答您的具体问题：
1) 我会选择 ADO 只是因为它更流行，并且相同的 API 可以用于其他类型的脚本，如 LDAP/ActiveDirectory 访问、读取文件系统文件夹、读取 MAPI 邮件以及使用其他类型的半-结构化文本文件，如固定宽度文本和 CSV。它并不是特别适合 HTA 编程环境，但可能更适合您学习更广泛适用的 API。我也认为它是一个更容易使用的 API，但我是从它开始的，后来才在一些较旧的 DAO 项目上工作。
2) ADO 提供的一个可能的好处是断开连接的记录集，这可能具有优势或至少在您的无线网络设置中提出了一些架构替代方案。您打开一个记录集，然后断开它，因此您仍然可以使用内存中的数据，但不必保持数据库连接处于打开状态。然后稍后您可以重新连接并更新数据库。此外，您可以通过将表作为本地 XML 或 ADTG 文件进行管理，以完全断开连接的方式工作。
您可能会强迫 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 进行压缩和修复。它提供了许多优点。
如果您可以负担得起将 HTA 应用程序与 Access 一起使用，而不是使用性能更高的平台，我会说您应该使用最简单的 api。在您的情况下，瓶颈永远不会是数据库访问的抽象。不过，DAO 真的很老了。