现有的DAO代码是否可以对抗SQL Server？

Question

如果我将数据从Access MDB传输到SQL Server，VB应用程序中的DAO代码将对SQL Server起作用。

我意识到需要对初始连接调用进行更改，但还有其他需要更改吗？

Answer 1

这里有很多问题。

1. 如果您使用ADP作为SQL Server的前端，则不会使用DAO，因为您不能，因为ADP不使用Jet / ACE。然后，您将与SQL Server建立直接ADO连接。

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

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

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

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

ADO的明智使用通常是有道理的，因为ADO在某些方面表现得非常出色，DAO表现不佳或根本没有。

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

一些随机问题：

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

2. 所有表都有主键至关重要，否则您可能会有奇怪的屏幕更新。但你们所有的桌子都有PK，对吗？

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

4. 如果您使用直通查询或ODBCDirect，则需要担心服务器数据库的SQL方言，并确保Jet / ACE正在处理哪个SQL（并将其解释为后端方言）哪个是直接进入服务器。

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

6. 如果您使用ADO，请记住ADO使用Access调用“SQL 92兼容模式”，这意味着SQL Server通配符和派生表语法。

Answer 2

这完全取决于您与数据库的交换方式：

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

Answer 3

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

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

Answer 4

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

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

我之所以提到这一点，主要是因为你提到DAO和VB（我假设是VB 5/6而不是VB.NET），它们是相当古老的技术，而Access MDB可能是一种类似的旧格式。