请记住，我不是 Access 大师。我精通 SQL Server 和 .Net 框架。这是我的情况：
一个承包商为我的公司构建了一个非常大的 MS Access 2007 应用程序。
该应用程序已按访问分为两层；有一个前端部分保存所有的 Ms Access 表单，然后是后端部分，它们是存储在网络上的计算机上的访问表、查询等。
当然，需要将数据存储部分转换为 SQL Server 2005，同时保留所有这些在 Ms Access 中构建的 GUI 表单。这就是我进来的地方。
我读了一点，发现您可以将表单甚至访问表链接到 SQL Server 表，但我仍然不确定到底可以做什么以及如何做。
有人做过吗？请评论有关此类工作的任何能力、限制和注意事项。谢谢！
不要使用 Access 中的升迁向导：
首先，它不适用于 SQL Server 2008。
其次，有一个更好的工具来完成这项工作：
SSMA，Microsoft 免费提供的SQL Server Migration Assistant for Access 。
它会为你做很多事情：
我最近写了一篇关于它的博客文章。
您有几个选择，升迁向导在将结构和数据从访问 Sql 中移动方面做得不错。然后，您可以设置链接表，以便您的应用程序“应该”像现在一样工作。不幸的是，Access 使用的 Sql 方言与 Sql Server 不同，因此如果代码中有任何“原始 sql”语句，它们可能需要更改。
尽管 Access 的所有其他功能、QBE、表单等都应按预期工作，但您已链接到表。这是最简单也可能是最好的方法。
解决该问题的另一种方法是如上所述迁移数据，然后在访问范围内使用 ADO，而不是使用链接表。如果您习惯于其他语言/开发环境，这种方法有点熟悉，但这是错误的方法。Access 带有大量内置的东西，使处理数据变得非常容易，如果你重新使用 ADO/Sql，那么你就会失去许多这些好处。
我建议从应用程序的一小部分开始 - 非必要数据，然后迁移一些表，看看它是如何进行的。当然，您首先要备份所有内容。
祝你好运
其他人建议将 Jet 后端升级到 SQL Server 并通过 ODBC 进行链接。在理想的世界中，该应用程序无需更改任何内容即可完美运行。
在现实世界中，您会发现一些被设计为与 Jet 后端一起高效和快速的前端对象实际上不能很好地与服务器数据库一起使用。有时 Jet 猜错了，会向服务器发送一些非常低效的东西。对于记录的大规模更新尤其如此——为了不占用服务器资源（一件好事），Jet 将为每条记录发送一个 UPDATE 语句（这对您的应用程序来说是一件坏事，因为它太多太多了比单个 UPDATE 语句慢）。
您需要做的是在升级应用程序后评估应用程序中的所有内容以及存在性能问题的地方，将一些逻辑移至服务器。这意味着您可以创建一些服务器端视图，或者您可以使用直通查询（将整个 SQL 语句交给 SQL Server，而不让 Jet 担心），或者您可能需要在服务器上创建存储过程（特别是对于更新操作）。
但总的来说，假设其中大部分内容无需更改即可正常工作，这实际上是相当安全的。它可能不会像旧的 Access/Jet 应用程序那么快，但您可以使用 SQL Profiler 来找出阻塞是什么，并重新构建事物以提高 SQL Server 后端的效率。
如果 Access 应用程序已经被高效设计（例如，表单永远不会绑定到完整的表，而是绑定到具有限制性 WHERE 子句仅返回 1 或几条记录的记录源），那么它可能会运行得很好。另一方面，如果它使用了 Access 示例数据库和模板中的大量不良做法，您可能会遇到巨大的问题。
我认为，每个 Access/Jet 应用程序都应该从一开始就设计为总有一天它会被放大以使用服务器后端的想法。这意味着 Access/Jet 应用程序实际上将非常高效和快速，而且当您升级时，它会造成最小的痛苦。
这是您成本最低的选择。您将要为指向 SQL Server 的 Access 客户端设置 ODBC 连接。然后，您可以使用（我认为）“导入”选项通过 ODBC 源将表“链接”到 SQL Server。将您的数据从 Access 表迁移到 SQL Server，您可以在 SQL Server 上以您可以管理和备份的形式保存您的数据。重要的是，查询可以在 SQL Server 上作为视图编写，也可以作为链接表呈现给 Access db。
链接访问表工作正常，但我只将它们与 ODBC 和其他数据库（Firebird、MySQL、Sqlite3）一起使用。有关主键或外键的信息没有通过。数据类型解释也存在问题：MySQL 中的日期与 Access VBA 中的日期不同。我猜这些问题在使用 SQL Server 时并没有那么严重。
要点：如果您将 Access 中的表链接到 SQL Server，那么每个表都必须定义一个主键（承包商？访问？经验表明，可能有些表没有 PK）。如果未定义 PK，则 Access 表单将无法更新和插入行，从而有效地将表呈现为只读。
看看这个 Access to SQL Server 迁移工具。它可能是少数（如果不是唯一的话）真正的点对点或服务器到服务器迁移工具作为纯 Web 应用程序运行的工具之一。它主要使用 ASP 3.0、XML、文件系统对象、数据字典对象、ADO、ADO 扩展 (ADOX)、字典脚本对象和其他一些简洁的 Microsoft 技术和技术。如果您在一台服务器上拥有源访问表，而在另一台服务器甚至同一台服务器上拥有目标 SQL Server，并且您希望将其作为 Web Internet 解决方案运行，那么这就是适合您的产品。此示例讨论了 VPASP 购物车，但它适用于任何版本的 Access 以及从 SQL 2000 到 SQL 2008 的任何版本的 SQL Server。
我正在完成通用数据库升级转换过程的开发，该过程涉及将 VPASP 购物或任何其他访问系统中的访问表、视图和索引结构自动转换为其 SQL Server 2005/2008 等效项。它直接从您的服务器运行，无需外部员工或顾问的任何外部帮助。
在 SQL Server 中创建 Access 表、索引和视图的克隆后，此数据迁移例程将选择性地将 Access 表中的所有数据迁移到新的 SQL Server 2005/2008 表中，而无需提供实际的 Access 数据库或表格内容或您的密码给任何人。
这是针对具有近 200 个表和近 300 个索引和视图的系统运行的过程的逆向工程部分，这是作为系统验收测试完成的。仍在进行中的工作，但核心部分已经到位。
http://www.21stcenturyecommerce.com/SQLDDL/ViewDBTables.asp
我对 Access Table DDL（数据定义语言）进行自动逆向工程，并将它们转换为 SQL 等效的 DDL 语句，因为对于每个 VPASP 客户和每个版本的 VP-ASP，表结构甚至额外的表都可能略有不同.
我正在完成实际的数据转换例程，该例程将在创建这些新 SQL 表（包括任何视图或索引）后将数据从 Access 迁移到 SQL Server。它完全用 ASP 编写，包含 VB 脚本、文件系统对象 (FSO)、字典对象、XML、DHTML、JavaScript，并且运行速度非常快，正如您在 SQL Server 2008 数据库中看到的那样例子。
对近 500 个不同的数据库对象进行逆向工程可能需要 15-20 秒。对于涉及的 170 个表和 270 个索引，此示例中可能总共涉及 2,000 多个列。
我什至想出了一种方法，让您在同一台服务器上使用 2 个不同的数据库连接文件并行运行两个 VPASP 系统，以确保在 Access System 和 SQL Server 系统上输入的订单在实际切换之前产生相同的结果到生产。
John (a/k/a The SQL Dude) sales@designersyles.biz （这是一个 VP-ASP 演示站点）
这是我听过一位开发人员谈到的一种技术。这是如果你真的想要一个客户端-服务器应用程序之类的东西。
一旦您决定如何使用单个表单来执行此操作，将相同的技术应用于其他表单并不难。在本地表上使用表单的好处是您可以将许多现有功能保留为现有应用程序（这就是他们使用并继续使用 Access 我希望的原因）。您只需要解决在 SQL Server 中来回获取数据的问题。
您可以继续拥有链接表，然后随着时间和性能需求的要求，使用这种技术逐步淘汰它们。
由于每个用户都有自己的本地文件，因此他们可以处理数据的本地副本。仅应在本地复制完成任务所需的最低要求。示例：如果他们正在更新单个记录，则表将只有该记录。当用户添加新记录时，您会注意到记录的 ID 字段为 Null，因此需要插入语句。
我猜本地表就像 .NET 中的数据集？我敢肯定，在某种程度上，这是一个不完美的类比。