Access 数据库迁移到 SQL Server 实战

dbaai

Access 数据库迁移到 SQL Server 实战

一、具体的问题

很多单位早年用 Access（.mdb / .accdb）搭了进销存、考勤、小业务系统，跑着跑着就遇到三道墙：单文件超过 2GB 直接报错打不开、十来个人同时写就开始频繁"数据库已被别的用户锁定"、关键表没有备份一旦硬盘坏掉就全丢。于是老板一句"把 Access 迁到 SQL Server"，但真正动手的人马上卡住：表、查询、窗体、宏怎么搬？自增字段、日期、是/否类型在 SQL Server 里怎么对？老程序连接串要不要改？本文把这条最经典的迁移路线一次走通，让你拿到一台空 SQL Server 就能照着落地。

二、核心原理

1. 为什么不直接"另存为"

Access 的查询（Query）本质是 JET SQL，和 SQL Server 的 T-SQL 在语法、函数、类型上有差异。比如 Access 用 IIF()、Date()、& 做字符串拼接，而 SQL Server 用 CASE WHEN、GETDATE()、+；Access 的"是/否"是布尔，SQL Server 对应 BIT；Access 自动编号对应 SQL Server 的 IDENTITY。所以迁移不是文件格式转换，而是把"数据 + 结构 + 逻辑"分批映射过去。

2. 三条迁移路线对比

• SSMA（SQL Server Migration Assistant）：微软官方免费工具，能自动把表结构、数据、甚至大部分查询/索引批量转过去，最省事，适合表多、人手紧的场景。
  
• 导出 CSV + BULK INSERT / bcp：先把 Access 各表导出为文本，再用 SQL Server 的导入向导或 bcp 灌入，适合数据量极大、想完全掌控字段映射的场景。
  
• Access 自带的"升迁向导"（Upsizing Wizard）：Access 内置，能生成 SQL Server 表并把数据推过去，但选项少、对复杂对象支持弱，只适合极简单的库。
  

绝大多数情况下，优先选 SSMA，它能在迁移报告里把"哪些对象成功、哪些需手工处理"列得清清楚楚，省下的调试时间远超工具学习成本。

3. 最容易翻车的几个类型映射

• 自动编号 → 必须设成 INT IDENTITY(1,1) 或 BIGINT IDENTITY，否则老代码里 INSERT 不带主键会报错。
  
• 是/否 → BIT，注意 Access 里 True=-1，SQL Server 里 1 为真，老程序的判断逻辑要核对。
  
• 文本 → Access 的"备注"对应 VARCHAR(MAX) 或 NVARCHAR(MAX)，短文本对应 NVARCHAR(n)，中文务必用 N 前缀避免乱码。
  
• 日期/时间 → DATETIME 或 DATETIME2，Access 的 Date() 在 T-SQL 里换成 CAST(GETDATE() AS DATE)。
  

三、实例参考（动手步骤）

下面以一台空的 SQL Server 2019 + 一个 oldbiz.accdb 为例，走通 SSMA 路线。

1) 安装并打开 SSMA for Access，新建项目，连接到源 Access 文件：

2. # 在 SSMA 图形界面操作
3. File -> New Project -> 选 SQL Server 2019
4. Connect to Access -> 选择 oldbiz.accdb

复制代码

2) 连接目标 SQL Server（Windows 身份或 SQL 账号均可），创建目标数据库：

2. CREATE DATABASE oldbiz_ssma
3.   ON (NAME=oldbiz_data, FILENAME='D:\Data\oldbiz_ssma.mdf', SIZE=512MB, FILEGROWTH=128MB)
4.   LOG ON (NAME=oldbiz_log, FILENAME='D:\Data\oldbiz_ssma.ldf', SIZE=256MB, FILEGROWTH=64MB);

复制代码

3) 在 SSMA 左侧选中要迁的表，右键 Convert Schema，再 Synchronize with Database 把结构推到 SQL Server；然后 Migrate Data 灌数据。迁移完成后务必看"迁移报告"里有没有红色错误。

4) 验证数据一致性（行数对得上才算成功）：

2. -- 以 orders 表为例，对比源 Access 记录数与目标行数
3. SELECT 'orders' AS tbl, COUNT(*) AS cnt FROM dbo.orders;
4. -- Access 侧可在查询里 SELECT COUNT(*) FROM orders 核对

复制代码

5) 把老程序的连接串从 Access 改为 SQL Server（以 ODBC 为例）：

2. # 旧（Access/JET）
3. Driver={Microsoft Access Driver (*.mdb, *.accdb)};DBQ=C:\data\oldbiz.accdb
4. # 新（SQL Server / ODBC Driver 17）
5. Driver={ODBC Driver 17 for SQL Server};Server=127.0.0.1,1433;Database=oldbiz_ssma;Trusted_Connection=Yes

复制代码

6) 前后对比：迁移前 Access 单文件 1.9GB、5 人并发就锁表；迁移后 SQL Server 单表 200 万行查询稳定在毫秒级，备份可用完整+日志实现按时间点恢复，彻底摆脱"文件一坏全没"的风险。

四、实操检查清单

• 迁移前对 Access 做一份完整备份（复制 .accdb + 压缩修复一遍），防止中途出错无法回退。
  
• 先用 SSMA 的"评估报告"扫一遍，把报错对象（复杂查询、宏、报表）单独列出来，报表类对象 SQL Server 不接收，需另想办法。
  
• 自动编号字段迁移后确认已是 IDENTITY，并核对旧数据的最大主键值，避免新插入冲突。
  
• 中文文本统一用 NVARCHAR（N 前缀），迁移后用 SELECT 抽几条中文记录确认无乱码。
  
• 是/否字段转 BIT 后，老程序里 =-1 的判真逻辑要改成 =1 或 <>0。
  
• 数据灌完后逐表 COUNT(*) 对账，行数不一致先查 SSMA 迁移报告的跳过项。
  
• 连接串切换后，先在测试环境用老程序跑通一条"增删改查"主流程，再上生产。
  
• 迁移成功后立即做完整备份并验证可恢复，别等出事才想起没备份。
  

五、收尾建议

迁移完成不要马上删 Access 原文件。建议保留至少一个月的并行运行期：新库正式接业务，老 Access 只读存档，两者数据每天抽核一次，确认无误再彻底下线。这样即便 SQL Server 端有遗漏的对象或逻辑，也能从 Access 里快速找回， Migration 才真正稳妥。