SQL Server .bak文件不可向低版本还原，必须用Navicat“转储SQL文件”导出兼容脚本（选目标版本模式、勾选结构与数据、含IF NOT EXISTS），再分批导入；避免直接还原报错3241。
直接用“还原备份”在低版本上必然失败
sql server 的 .bak 文件是向前兼容、不向后兼容的。比如 sql server 2019 备份的文件，无法被 sql server 2016 或 2012 直接还原——navicat 界面里点“还原”，底层执行的仍是 restore database，报错信息通常是：msg 3241, level 16, state 7, line 1: the media family on device '' is incorrectly formed. 这不是 navicat 的 bug，而是 sql server 引擎层硬性限制。
用“转储 SQL 文件”导出+导入是最可靠路径
本质是把高版本数据库“翻译”成标准 T-SQL 语句，绕过二进制备份格式。操作时必须注意三件事：
- 右键源库（高版本）→
转储 SQL 文件→ 勾选“结构”和“数据”； - 在“选项”页中，务必选择目标低版本对应的兼容模式（如 SQL Server 2008/2012/2014），否则可能导出
STRING_AGG、SEQUENCE等低版本不支持的语法； - 勾选“包含 IF NOT EXISTS”，避免建表重复报错；取消勾选“导出外键约束”，防止因建表顺序错乱导致导入中断。
导入时几个典型报错及绕过方式
即使选了兼容模式，仍可能卡在以下环节：
-
Cannot find the object "xxx"：说明脚本中存在依赖（如视图引用未创建的表）。Navicat 默认按字母序建表，不保证依赖顺序。解决方法是先导入所有表结构和数据，再单独执行外键/视图/存储过程脚本； -
IDENTITY_INSERT is set to OFF：插入带自增主键的表时报错。需在对应INSERT INTO语句前手动加SET IDENTITY_INSERT [table_name] ON，结束后加OFF； - DATETIME2 字段报错：虽然兼容模式会自动降级为
DATETIME，但如果脚本里残留了DATETIME2(3)，得全局搜索替换为DATETIME（SQL Server 2005 及更早不支持 DATETIME2）。
大文件导入容易中断，别全靠 Navicat 执行
Navicat 默认用单事务提交整个 SQL 文件，一旦中途失败，全部回滚，重试成本高。实际处理百万级以上数据时：
- 导出后手动拆分 SQL 文件（例如按表切分），用
sqlcmd分批执行； - 或改用
BCP工具导出/导入数据（比 SQL 脚本快一个数量级），结构仍用 Navicat 导出的兼容 DDL； - 若必须用 Navicat 导入，建议关闭“自动提交事务”，并在导入前确认目标库已设为
RECOVERY SIMPLE模式，减少日志压力。
真正麻烦的从来不是点击几下菜单，而是导出脚本里那些看不见的隐式依赖、类型降级残留、以及事务粒度失控——这些细节不提前检查，导入到 99% 时失败，最耗心力。
