将Access数据库迁移到基于SQL Server的应用程序有哪些策略?

几年前,我们遇到了类似的情况,但我们从一开始就知道,总有一天我们将不得不切换到SQL Server,因此整个代码都是从访问客户机写入到Access和SQL Server数据库的。

“一步”迁移到SQL Server的想法无疑是在数据库端管理这一点的更简单的方法,而且有许多工具可以做到这一点。但是,根据客户端应用程序与数据库的对话方式,您的代码可能无法正常工作。例如,如果您的代码包含许多SQL指令(或在运行时生成它们,例如,为选择指令添加筛选器),则您的语法可能与“SQL Server”不兼容:访问通配符、日期、函数在SQL Server上不起作用。

除此之外,正如@mjv所说,一次性切换到MS SQL的另一个缺点是,您将从原始数据库继承许多问题:错误或不适当的字段名、不适当的主键/外键策略、隐藏希望在新数据库模型中实现的一对多关系等。

我将在这里提出一些原则和规则来实现“软过渡”解决方案,这显然最适合您。只是说这不容易,但这绝对是非常有趣的,耐心地处理300张桌子!你真幸运!

我假设您有能力更新客户机代码,并且您希望始终保持相同的客户机接口。当然,在转换时可能有两个不同的接口,一个用于每个数据库,但是这对于用户来说是非常混乱的,对于他们来说是一个永久的挫折源。

据我所知,最佳解决方案主要取决于:

1. 原始连接技术, 以及在您的 客户端代码:访问链接表, ODBC、ADODB、记录集、本地 表、窗体记录源、批处理 更新等。
2. 将您的 你的应用程序和桌子 独立模块。

您将不会放弃以下强制性活动:

1. 传输的设置 从Access数据库到SQL Server的过程。你 可以使用现有的工具 访问升迁向导非常差, 所以不要犹豫买一个真正的 一个,如ssw或ems-sql-manager, 或者建立自己的 一个是Visual Basic。如果你的计划 是对数据进行一些更改 定义,你肯定会 写一些代码。牢记 您将运行此代码 Maaaaa任何时候,请确保 它包括所有的节省时间 使用说明 从头开始重新启动进程 尽可能多次。你会 必须在两个基本数据之间进行选择 导入数据时的导入策略:

    a - DELETE existing record, then INSERT imported record
    b - UPDATE existing record from imported record
   

   如果计划切换到新的主键\外键类型,则必须在转换期间跟踪新数据库模型中的旧标识符。在这个阶段,不要犹豫切换到guid主键,特别是如果计划在某一天在多个站点上复制数据。

   此传输过程将被划分为与前面定义的“逻辑”模块相对应的模块,并且您应该能够独立地运行这些模块中的任何一个(当然要记住,它们可能必须以特定的顺序执行,其中“客户”模块必须在“开发票”模块之前运行)。

2. 在客户端代码中实现连接到原始MS Access数据库和新MS SQL Server的可能性。理想情况下,您应该能够从代码中管理显示和验证数据的连接。

   这种可能性将由模块实现,在模块中,每个模块都有一个“试用期”,即在使用模块时,可以在测试时在访问连接和SQL连接之间进行选择。一旦测试完成,模块就可以在独占的SQL Server模式下运行。

在传输期间(可能会持续几个月),您必须通过编程方式管理“SQL Server”模块和“Access”模块之间存在的数据库约束。回到我们的客户/发票示例,客户模块将首先切换到MS SQL。在切换发票模块之前,您必须以编程方式实现客户和发票之间的一对多关系,其中每个表都将位于不同的数据库中。这样的约束可以通过在“客户”组合框中填充来自SQL Server的客户记录集来实现。

我的建议是 按照数据库模型构建模块 ,从“一”表或“一对多”关系开始:应首先切换基本列表,如“单位”、“货币”、“国家”。在编写数据传输代码和管理客户机接口中的第二个连接方面,您将拥有第一次“动手”的经验。然后,您就可以在数据库模型中“向上”切换“产品”和“客户”表(其中单位、国家和货币是外键)到新服务器。

祝你好运!

您可能会发现主要问题是使用MS Access Jet引擎作为后端。我假设您对除表之外的所有对象都有一个访问FE(前端)和一个BE(仅后端表)。

您可能会发现,将数据迁移到SQL Server,并将访问FE链接到SQL Server,将有助于立即缓解问题。

然后,如果您不想继续使用MS Access作为FE,可以考虑将其分解为“模块”,并使用单独的开发平台逐个重新设计模块。

我建议将后端升迁到SQL Server作为第1步。

不过,我绝不会去建议的步骤2(即,用其他东西替换访问前端)。相反,我建议投入精力来修复模式的缺陷,并调整访问应用程序以使用新的模式。

很明显,当你升迁的时候,一切都会好起来,这是不可能的——一些以前很快的东西会是狗,而一些以前很慢的东西会很快。我发现问题经常出现 不 你预计他们会在哪里。您只能通过测试找出需要修复的内容。

基本上,任何工作不好的东西都会被重新设计,或者完全移动到服务器端。

利用现有接入应用程序的投资,而不是抛开所有这些,从头开始。对于SQL Server后端来说,访问是一个很好的前端,只要您不认为它的工作方式与Jet/Ace后端的工作方式相同。

…大声思考…我想这可能有效。

我发现应用程序的复杂性存在于各种VBA模块中,而不是数据库表/模式本身。因此,可能的迁移路径是 首先将数据存储迁移到SQL Server ,完全一样,如下:

• 在几个小时内防止对数据进行任何更改
• 将所有表复制到SQL Server;确保创建相同的索引。
• 创建指向SQL Server上新创建表的ODBC源的链接表
  这些表应该与原始表具有非常相同的名称(因此可能需要重命名,例如使用前导下划线,以供参考)。
• 现在,应用程序可以重新启动,应该使用SQL表而不是访问表。所有的逻辑都应该像以前那样工作(右…),根据两台机器之间的距离,可能出现的缓慢。

所有这些都可以在一天左右的工作中进行测试;最乏味的是在SQL Server上创建表(我敢肯定,其中大部分都可以自动化)。下一个最乏味的任务是断言应用程序和以前一样有效地工作,但是它的存储在SQL上。
编辑 :正如一个评论所建议的,我应该强调有一个[公平吗?]应用程序可能无法在SQL Server后端下如此顺利地工作,并且可能需要数周的测试和修复工作。但是,除非由于对问题中未表达的应用程序的深入了解,可以预见其中的一些困难,否则我建议应该考虑尝试“原样”迁移到SQL Server;毕竟,它可能只需要最少的努力就可以工作,如果不这样做,我们很快就会知道这一点。因此,这是一个高回报、低风险的建议……

主要 优势 用这种方法寻求的是,在[正如操作人员预期的那样]更长的时间内,将有一个单独的存储,在此期间,旧的访问应用程序将与新的应用程序共存。

这个 缺点 这种方法是,至少在一开始,复制原始数据库的模式 逐字逐句的 也就是说,包括一些已知的怪癖和遗留下来的特质。这些模式问题(以及基础应用程序逻辑)可以及时纠正,但这当然比新应用程序启动时要容易得多。 从头算 具有自己的、独立的、存储的和独特的模式。

将存储移到SQL Server后,可以在新应用程序中重新写入访问应用程序中使用最多和/或最独立的模块,并且随着原始应用程序的重要部分被移植,通过选择测试版测试人员或实际用户可以开始切换到新应用程序。

可能,可以使用某种基于屏幕抓取的逻辑或其他系统来生成一个混合应用程序,它将为最终用户提供一个全面的应用程序,有时使用新的逻辑,有时使用原始的MS访问程序。