现有的 DAO 代码是不是适用于 SQL Server？

Posted 2023-04-18

【中文标题】现有的 DAO 代码是不是适用于 SQL Server？

【英文标题】：Will existing DAO code work against a SQL Server?现有的 DAO 代码是否适用于 SQL Server？

【发布时间】：2011-02-20 22:43:50

【问题描述】：

如果我将数据从 Access MDB 传输到 SQL Server，VB 应用程序中的 DAO 代码是否适用于 SQL Server。

我知道需要对初始连接调用进行更改，但是否还有其他需要更改的地方？

【参考方案1】：

这里有很多问题。

如果您将 ADP 用于 SQL Server 的前端，您将不会使用 DAO，因为您不能，因为 ADP 不使用 Jet/ACE。然后，您将拥有与 SQL Server 的直接 ADO 连接。

但是，在过去 5 年左右的时间里，MS 一直在弃用 ADP，转而支持使用 ODBC 的 MDB/ACCDB（某些报告方案除外）。 A2007 和 A2010 中的 ADP 没有任何变化，这可能表明 MS 计划完全放弃它们（就像他们在 A2002 和 A2003 没有变化后对 DAP 所做的那样）。但也可能是 MS 计划在下一版本的 Access 中恢复 ADP，因为 Access 团队一直在积极寻求那些使用 SQL Server 的人的意见。

使用推荐的技术 (MDB/ACCDB) 和 ODBC（可能还有链接表），您使用的是 Jet/ACE，逻辑数据接口是 DAO，Jet/ACE 的本机数据接口。

Jet/ACE 在处理服务器数据库方面实际上非常聪明，但它确实会出错，而且没有经验的 Access 开发人员可能会编写某些类型的查询，这将成为服务器数据库的性能猪（因为它们强制Jet/ACE 从服务器拉出整个表并在客户端工作站上完成所有工作——参见上面@Philippe Grondier 的回答。

通过 MDB/ACCDB 中的 ODBC 使用 SQL Server 的常用方法是尝试使用 Access 方式，绑定表单和整个九码（与您设计与 Jet/ 一起使用的应用程序没有什么不同） ACE 后端），然后使用 SQL Profiler 确定哪些部分是性能瓶颈并应进行重组，以便在服务器端进行适当的处​​理。

通常需要明智地使用 ADO，因为 ADO 在某些方面做得非常出色，而 DAO 做得很差或根本没有。

但基本思想是使用与 Jet/ACE 后端相同的方法，因为 Jet/ACE 正在管理您与服务器的接口。这意味着您不必担心 Jet/ACE 的 SQL 方言和服务器数据库的方言之间的差异，因为 Jet/ACE 和 ODBC 完全消除了这些差异。

一些随机问题：

对于 DAO 记录集，您需要添加 dbSeeChanges 选项。

您的所有表都必须有一个主键，否则您可能会有奇怪的屏幕更新。但是你们所有的桌子都有PK，对吧？

我发现最好在 SQL Server 上的所有表中放置一个时间戳字段，即使我从未明确使用它。这（结合 #2）确保刷新尽可能高效（ODBC 可以检查时间戳，而不需要将所有客户端字段与服务器端值一一进行比较）。

李> 1234563并且直接连接到服务器。

Jet/ACE 没有与 bigint 对应的数据类型，因此如果您在 SQL Server 表中将其用作 PK，则需要以非标准方式处理它。 MS 知识库中有关于解决此问题的文章。

如果您使用 ADO，请记住 ADO 使用 Access 所谓的“SQL 92 兼容模式”，即 SQL Server 通配符和派生表语法。

【讨论】：

为什么需要添加 dbSeeChanges 选项？为什么你需要在所有桌子上都有 PK？这两个问题有什么风险？我只打算使用 DAO。

我不确定 dbSeeChanges 的原因，但我相信这是我在运行代码时收到的错误消息。或者也许我是从 Baron/Chipman 那里得到的。我实际上并没有在其中的任何地方看到它，所以我很确定错误消息会推荐它。

对于 PK，它在更新数据方面与绑定表单有所不同。如果没有 PK，ODBC 必须获取所有字段的值并制作一个假密钥，如果这不是唯一的，它必须制作一个合成密钥来判断正在更新的记录（我有点模糊这也可能是 SQL Server 问题）。 ODBC 还能如何告诉服务器要更新哪条记录？在没有真正的 PK 的情况下，必须有某种东西作为 PK 来将 Access 中显示的记录与 SQL Server 表中的相应记录联系起来。

...当然，根据关系数据库和 SQL 的基本规则，没有 PK 的表实际上并不是数据库的一部分。我从来没有遇到过这个问题，因为我从来没有创建过没有 PK（自然或代理）的表。

【参考方案2】：

这完全取决于您如何与数据库进行交换：

您在代码或访问查询中使用“SQL 类型”指令，例如“INSERT INTO bla(...)”：您必须检查您的代码是否符合 SQL。有许多 Access（或者我应该说 Jet？）函数，例如 isul()，必须在 SQL 中重新解释 您正在操作 DAO 记录集以进行更新、插入和删除。一旦使用正确的 SELECT 指令（参见前面的...）、正确的连接字符串和服务器上的正确授权打开记录集，您应该就可以了。

【讨论】：

您的 #1 取决于调用 Access/Jet 函数的位置。在 WHERE 子句中用作比较一侧的列上的 IsNull() 只会在没有其他条件的情况下导致大问题。也就是说，它将拉整个表客户端。如果还有其他条件，则提取的记录数可能（但不一定）小得多，因为 Jet 查询优化器将在满足所有其他条件后最后应用表达式条件。不好，但也不是灾难性的（不比 Jet/ACE 本身更糟）。

难以置信！您是否有一个秘密/私人“Jet”标签来跟踪提到这个词的答案？当我输入魔法词时，我只是在想它......

【参考方案3】：

直接没有。但是您可以将当前访问表替换为与 sql server 的链接表。

更新：How to create a DSN-less connection to SQL Server for linked tables in Access

【讨论】：

使用DAO直接连接SQL Server有什么问题？

Dao 未针对多用户/远程数据库环境进行优化

关于如何在 SQL Server 中使用 DAO 时如何解决问题的信息并不多，而且 DAO 仅支持“始终开启”连接。如果您只使用选择和插入，那么可能没问题，否则我会选择切换到 ADO.Net。我见过 MSAcess 到 .net 应用程序的转换器

如果您认为 DAO 没有针对 SQL Server 进行优化，请等待多个用户连接到同一个 mdb 文件，其中的表链接到 SQL Server。

您不能直接将 SQL Server 与 DAO 一起使用（就像使用 ADO 一样），而只能通过 ODBC。而且 Jet（即 DAO 的底层引擎）非常了解 ODBC，因此将 DAO 与 ODBC 链接表一起使用（或在 SQL 语句中指定 ODBC 连接字符串）并没有真正的危险。

【参考方案4】：

不确定这是否适用于您的方案，但 Access 中的 SQL 语法（至少是旧版本）与 SQL Server 的语法略有不同，例如旧版本 Access 中的 LIKE 通配符使用 * 而不是SQL Server 使用的百分比。

如果您在 VB 应用程序中使用 SQL 查询，您可能需要确保所有 SQL 语句都符合 SQL Server 语法。

我提到这主要是因为您提到了 DAO 和 VB（我假设是 VB 5/6 而不是 VB.NET），它们是相当古老的技术，而 Access MDB 可能采用类似的旧格式。

【讨论】：

DAO 在长期存在方面已经过时，但仍在积极开发中，在 A2007 和 A2010 中得到了显着改进。

感谢您的提醒，大卫。真的没有意识到这一点，将通过 DAO/JET 3.5 访问 MDB 的 VB6 应用程序移植到 ADO，然后最终移植到 SQL Server，可能是五年前。不知道它还存在，当时认为它已被 ADO 弃用。

DAO 可能已在 Access 2000 天被弃用，但现在 ADO 已被 MS 弃用，DAO 又回来了。头晕了吗？

是的，差不多。真是让人摸不着头脑。我真的需要更新自己。

顺便说一句，以前称为 DAO 现在称为 ACE 不是吗？