简介：Wi6.5数据库（随心所欲XP工作站医疗数据库）面向医疗信息化开发者与Delphi/Interbase技术学习者，基于Interbase 6.5关系型数据库构建，可用于患者信息、诊疗记录、处方与费用等敏感数据的存储、检索和权限管理，也适合作为Windows XP工作站环境下数据库应用的复现、维护与二次开发参考。压缩包共967个文件、约28.43MB，内容以147个html说明页、138个dfm窗体、88个pas与67个c、66个cpp源码为主，并含44个exe、24个dll、20个sql、9个gdb数据库及hlp、pdf等文档，覆盖界面、程序逻辑、数据库文件与运行组件，便于核查模块依赖和部署环境。已有1004人学习，说明其在医疗数据库教学与老系统维护场景中具有一定参考价值。借助完整源码、表结构与权限控制示例，读者可梳理HL7/DICOM相关数据组织思路，对照窗体与数据表关系定位业务逻辑，理解备份恢复与加密机制，并用于排错、迁移评估或课程设计。
1. 一台不敢重启的 XP 工作站，和一个 200MB 的医疗库
某社区卫生服务站的收费窗口，机器是 2006 年装的 XP 工作站，机箱风扇已经开始发出异响，没人敢按重启键，因为上次非正常关机之后目录里留下一个.ldb锁文件，整个上午的挂号收费全部停摆。真正让值班的人头疼的其实不是老机器，而是里面那个 200MB 左右的医疗数据库：患者主索引里同一个人挂了三条记录，收费明细的金额和单价乘数量对不上，日结报表跑出来的数字没人敢往上报。这类现场不需要推倒重来，需要的是一套能把库看明白、能安全备份、能干净迁移的交付物。wi6.5 数据库（随心所欲 XP 工作站医疗数据库）就是按这个场景整理的：业务表结构、11 张基础字典、Jet 与 SQL Server 两套 DDL、旧版本字段映射表、五组校验查询，单机站直接跑.mdb，科室站换成 SQL Server 2000 脚本，两套 schema 字段名和类型对齐。适合还在维护老医疗站点的实施与运维、要把历史数据搬到新系统的开发者，以及想做课程设计、想看看真实 HIS 库长什么样的学生。
2. wi6.5 库的文件与表结构：四类核心表与 11 张字典怎么分工
拿到一个数据库交付包，先别急着双击打开。老医疗库最大的问题是“看起来能连上”，但字段类型、排序规则、约束级别三样东西一旦和你预期的不同，后面所有 SQL 都会在某个深夜给你一个惊喜。wi6.5 这个包的结构设计有明确的取舍痕迹，先把文件职责和表的分层看清楚，后面配置和迁移才知道自己在改什么。
2.1 交付目录：三个库文件、两份 DDL、一套校验脚本
包里的文件不是随手堆的，业务库、字典库、日志库拆成三个独立文件，是这套结构里最关键的一个决定。
| 文件 | 内容 | 建议部署位置 |
|---|---|---|
WI65_DATA.MDB | 患者主索引、就诊、收费明细等业务表 | D:\WI65\DB |
WI65_DICT.MDB | 11 张字典表，含科室、人员、收费项目 | 同上 |
WI65_LOG.MDB | 操作审计、错误日志、迁移批次记录 | 同上 |
schema_jet.sql | Jet DDL，建表、建索引、建查询 | D:\WI65\SCRIPT |
schema_mssql.sql | 科室站 DDL，含约束、默认值、触发器 | 同上 |
map_v60_v65.xlsx | 旧版本字段映射与转换规则 | D:\WI65\DOC |
chk_01至chk_05 | 五组校验查询，迁移和日结前各跑一遍 | D:\WI65\SCRIPT |
字典库单独拆出来，理由很实际：字典表更新频率低但被高频读取，科室改名、收费项目调价、诊断编码升级，这些操作一年也就几次，拆开之后可以直接用新的字典文件覆盖，完全不动业务数据。代价是 Jet 引擎不支持跨库外键，主库没法约束字典引用，所以主库的CHARGE_DETAIL里冗余存了ITEM_NAME和DEPT_NAME。冗余字段不是设计失误，是为了让报表不跨库 join，这一点在迁移时必须同步维护，否则明细里的科室名会和字典对不上。
日志库单独放还有一层考虑：老站点的磁盘经常只剩几百兆，日志表和业务表混在一起，一次异常刷屏就可能把主库撑爆。分开之后，日志库可以定期清空甚至直接删掉重建，不影响业务。
2.2 业务主线：患者主索引到收费明细的四个环节
整套库的主线是一条很短的链：患者主索引 → 就诊 → 收费明细 → 字典。理解这条链，比记住二十张表有用得多。
PAT_MASTER是患者主索引，主键PAT_ID是 12 位字符，规则是卡号 8 位加校验位 4 位，不用自增数字。这个选择在老医疗系统里很常见，因为卡号要在多台工作站之间离线生成，自增主键在断网时没法保证唯一。字段包括PAT_NAME、SEX（1 男 2 女 9 未知）、BIRTHDAY、ID_CARD、CARD_NO、PHONE、CREATE_TIME、STATUS（1 正常 2 合并 3 注销）。STATUS这个字段是合并功能的基础，后面第四章会用到。
VISIT是就诊记录，主键VISIT_ID，规则是日期 8 位加 4 位流水，字段有PAT_ID、DEPT_CODE、DOCTOR_CODE、VISIT_TIME、VISIT_TYPE（1 门诊 2 急诊 3 体检）、DIAG_CODE。一个人可以有多条就诊，所以PAT_ID上单独建了普通索引。
CHARGE_DETAIL是收费明细，主键DETAIL_ID，字段有VISIT_ID、PAT_NAME（冗余）、ITEM_CODE、ITEM_NAME（冗余）、QTY、PRICE、AMOUNT、PAY_FLAG（1 收费 2 退费）、CHARGE_TIME、OPERATOR。这张表是数据量增长最快的一张，一个日均 300 人次的站点，三年下来明细轻松过百万行。
11 张字典表分别是DICT_DEPT、DICT_STAFF、DICT_ITEM、DICT_DRUG、DICT_DIAG、DICT_PAYMODE、DICT_UNIT、DICT_FREQ、DICT_ROUTE、DICT_SPEC、DICT_SYS。前六张是业务强依赖，后五张是给药途径、频次、规格这类辅助字典，DICT_SYS存系统参数，比如日结时间点、票据号段、机构名称。
2.3 设计取舍：为什么没有外键、金额为什么不用浮点
这三处取舍直接决定了脚本怎么写，值得单独说清楚。
第一处是不建外键。Jet 引擎在批量INSERT时逐行校验外键约束，十万行明细插进去要等好几分钟，老站点的实施习惯是建表时不加约束，靠夜间的孤儿记录校验脚本回补。所以你会看到schema_jet.sql里只有主键和普通索引，没有FOREIGN KEY，schema_mssql.sql里才带约束和触发器。做迁移的时候，如果目标库是 SQL Server，插入顺序必须先字典后业务，否则触发器直接把整批数据挡回去。
第二处是金额用定点类型。Jet 里的CURRENCY是缩放 10000 的定点数，schema_mssql.sql里对应DECIMAL(18,2)，两套都不用DOUBLE。原因很直白：浮点累加会出现 0.009999 这种尾数，一千条明细汇总下来账面上就差几毛钱，收费窗口对不上账是最难解释的故障。金额字段一律走定点，四舍五入统一在应用层用ROUND(x, 2)处理，库里不做二次舍入。
第三处是日期字段的双轨制。老版本把VISIT_TIME存成TEXT(14)，格式yyyyMMddHHmmss，好处是排序即时间序、导出 CSV 不会变形成科学计数，坏处是没法做日期区间函数运算。wi6.5 统一改成DATETIME，同时保留VISIT_TIME_TXT兼容老报表。迁移脚本里必须两个字段同时写，且格式必须严格一致，这是后面第四章最容易翻车的地方。
注意：
schema_jet.sql通过 ADO 执行时，TEXT(n)等价于变长字符，LONG是备注型，不能建索引，也不适合放排序字段。
3. 在 XP 工作站上把库跑起来：引擎版本、连接串与初始化脚本
部署老数据库，翻车往往不在 SQL 上，而在环境。同一份.mdb在一台机器上打开正常，换一台就报“不可识别的数据库格式”，九成是 Jet 引擎版本或者排序规则不一致。这一章按“先核对环境、再建立连接、最后灌入初始化数据”的顺序走，每一步都有可验证的检查点。
3.1 环境核对清单：五项必须过
在动任何脚本之前，先把下面五项核对完。这几项不通过，后面所有步骤都是白费。
| 检查项 | 要求 | 检查方式 |
|---|---|---|
| Jet 引擎 | 4.0.8618 及以上 | 查msjet40.dll文件版本 |
| 数据访问组件 | MDAC 2.8 | 组件检查器确认版本 |
| 磁盘与权限 | NTFS，账户对库目录有修改权限 | cacls D:\WI65\DB |
| 区域设置 | 中文（中国），短日期yyyy-mm-dd | 控制面板区域选项 |
| 文件路径 | 全英文、无空格、无中文 | dir /x看 8.3 名称 |
路径这一项最容易忽略。Jet 在某些 OLE DB 提供程序下遇到中文路径或空格，会抛“找不到可安装的 ISAM”，报错信息完全不提路径问题，排查能耗掉半天。血泪经验是：部署目录一律用D:\WI65\，任何一层都不要带中文和空格。区域设置同样关键，短日期格式不是yyyy-mm-dd时，#2013-08-15#这种字面量在部分环境下会被按mm/dd/yyyy解析，查询结果直接跑偏。
权限用cacls确认，比在资源管理器里点属性可靠：
rem 查看库目录的访问控制，确认当前账户有 C（写入）权限 cacls D:\WI65\DB rem 给工作站操作账户授予修改权限 cacls D:\WI65\DB /E /G WI65USER:C第一条命令看清现有 ACL，第二条才动授权。/E表示在原有 ACL 上编辑而不是替换，少了这个参数会把继承来的权限全部冲掉，后果是管理员自己也进不去。/G后面跟账户和权限字母，C是修改（含读写删除），不要图省事给F（完全控制）。
3.2 用无 DSN 连接串，别在每台机器上手工配 ODBC
老资料里常见做法是到控制面板里配一个系统 DSN，然后程序里写DSN=WI65。这个做法在多工作站场景下是灾难：十台机器要配十次，哪台忘了配就报“找不到数据源”，而且 DSN 存在注册表里，重装系统就丢。更稳的方式是直接写无 DSN 连接串，把连接信息收进配置文件。
下面这段 VBScript 是部署后必跑的自检脚本，用来验证连接串、密码和库文件三者是否匹配：
' test_conn.vbs —— 放在 D:\WI65\SCRIPT 下，用 cscript test_conn.vbs 执行 Dim conn, rs, sConn Set conn = CreateObject("ADODB.Connection") ' Provider：走 Jet 4.0，不要写成 ACE，XP 上默认没有 ACE 引擎 ' Data Source：库文件绝对路径，不接受相对路径和 UNC 简写 ' Jet OLEDB:Database Password：库级密码，与工作组权限是两套机制 sConn = "Provider=Microsoft.Jet.OLEDB.4.0;" & _ "Data Source=D:\WI65\DB\WI65_DATA.MDB;" & _ "Jet OLEDB:Database Password=Wi65#2024;" & _ "Persist Security Info=False;" On Error Resume Next conn.Open sConn If Err.Number <> 0 Then WScript.Echo "连接失败 [" & Err.Number & "] " & Err.Description WScript.Quit 1 End If Set rs = conn.Execute("SELECT COUNT(*) AS C FROM PAT_MASTER") WScript.Echo "连接成功，患者主索引记录数：" & rs("C") rs.Close : conn.CloseProvider写Microsoft.Jet.OLEDB.4.0而不是ACE.OLEDB.12.0，是因为 XP 工作站默认没装 ACE 引擎，写了也白写。Data Source必须是绝对路径，UNC 路径在某些账户下会因凭据问题失败。Jet OLEDB:Database Password是库级密码，和工作组权限文件.mdw是两套完全独立的机制，前者防止用别的工具直接打开文件，后者控制谁能读写哪张表。Persist Security Info=False保证连接打开后密码不会留在连接对象里被程序读出来。
如果包里带的是工作组安全版本，还要加一个参数Jet OLEDB:System database=D:\WI65\DB\WI65.MDW，指向工作组文件，否则连上去会被当成管理员以外的匿名用户，读不到表。
3.3 初始化：建表、建索引、灌字典的顺序不能乱
初始化脚本的执行顺序是字典 → 业务表 → 索引 → 基础数据。先建业务表会导致种子数据插不进去，因为业务表的初始记录引用了字典项。
下面是schema_jet.sql里患者主索引那段 DDL，字段长度和类型都是按老站点实际数据定的，直接照抄改路径即可：
-- 患者主索引：卡号 8 位 + 校验位 4 位，故意不用自增 CREATE TABLE PAT_MASTER ( PAT_ID TEXT(12) NOT NULL, -- 主索引号，固定 12 位，禁止前导空格 PAT_NAME TEXT(40) NOT NULL, -- 姓名，兼容少数民族姓名长度 SEX TEXT(1) NOT NULL, -- 1 男 2 女 9 未知 BIRTHDAY DATETIME, -- 出生日期，允许为空（老病历常见） ID_CARD TEXT(18), -- 证件号，允许 15 位老身份证 CARD_NO TEXT(20), -- 就诊卡号 PHONE TEXT(20), CREATE_TIME DATETIME NOT NULL, -- 建档时间，用于日结与审计 STATUS TEXT(1) NOT NULL -- 1 正常 2 已合并 3 已注销 ); -- 主键用唯一索引实现，Jet 的 PRIMARY KEY 关键字在 ADO 下对复合键支持一般 CREATE UNIQUE INDEX PK_PAT_MASTER ON PAT_MASTER (PAT_ID); -- 姓名 + 生日组合索引，给“同名同生日”查重和合并功能用 CREATE INDEX IX_PAT_NAME_BIRTH ON PAT_MASTER (PAT_NAME, BIRTHDAY); -- 证件号普通索引，不唯一：历史数据里一人多证的情况真实存在 CREATE INDEX IX_PAT_IDCARD ON PAT_MASTER (ID_CARD);PAT_ID用TEXT(12)而不是CHAR(12)，Jet 没有定长字符类型，写了也是变长。PAT_NAME给 40 位是给少数民族姓名和生僻字留余量，实际数据里最长见过 27 个字符。BIRTHDAY允许为空，因为早年手工建档的病历大量缺失出生日期，如果设成NOT NULL，导入时会直接丢掉几千条历史记录。ID_CARD索引不设唯一，这是故意的：迁移前的体检脚本会查出重复证件号，但重复本身是业务事实，不能靠约束阻断。
索引建完，再灌字典。字典数据是INSERT语句，量大的是DICT_ITEM（收费项目）和DICT_DIAG（诊断编码），执行时用事务包一层：
-- 字典灌入示例，实际脚本里是成批的 INSERT INSERT INTO DICT_DEPT (DEPT_CODE, DEPT_NAME, DEPT_TYPE, SORT_NO) VALUES ('0101', '全科门诊', '1', 10); INSERT INTO DICT_ITEM (ITEM_CODE, ITEM_NAME, ITEM_TYPE, PRICE, UNIT) VALUES ('31010001', '普通门诊诊查费', '1', 5.00, '次');DEPT_TYPE区分临床、医技、药房，SORT_NO决定收费界面的下拉顺序，这两项在字典里缺了不会报错，但会让前端排序乱掉，属于典型的“能跑但不好用”。
3.4 首启动自检：五条 SQL 验收入口
初始化跑完，不要急着把程序连上去。先按顺序执行五条校验，把结构问题挡在业务数据进来之前。
-- chk_01：表是否齐全，应返回 14 行（3 业务表 + 11 字典表） SELECT COUNT(*) AS TAB_CNT FROM MSysObjects WHERE Type = 1 AND Name NOT LIKE 'MSys%'; -- chk_02：主索引是否重复，应返回 0 SELECT PAT_ID, COUNT(*) AS C FROM PAT_MASTER GROUP BY PAT_ID HAVING COUNT(*) > 1; -- chk_03：明细金额与数量乘单价是否一致，允许±0.01误差 SELECT DETAIL_ID, QTY, PRICE, AMOUNT FROM CHARGE_DETAIL WHERE ABS(AMOUNT - QTY * PRICE) > 0.01; -- chk_04：字典引用缺失（孤儿数据），应返回 0 SELECT C.DETAIL_ID FROM CHARGE_DETAIL C LEFT JOIN DICT_ITEM I ON C.ITEM_CODE = I.ITEM_CODE WHERE I.ITEM_CODE IS NULL; -- chk_05：日期越界，未来日期或 1900 年前的脏数据 SELECT PAT_ID, BIRTHDAY FROM PAT_MASTER WHERE BIRTHDAY > NOW() OR BIRTHDAY < #1900-01-01#;第一条查系统表MSysObjects，Type = 1是本地表，排除MSys开头的系统表，正常应该返回 14 行，数量不对说明建表脚本中途失败过。第三条的ABS(...) > 0.01容差不能设成 0，因为定点数在不同引擎间转换会有极小的表示差。第五条用了#...#日期字面量，这就是前面强调区域设置的原因：短日期不是yyyy-mm-dd的机器上，#1900-01-01#可能被解析成 1 月 1 日以外的日期，查出来的结果毫无意义。
4. 从旧库迁到 wi6.5：字段映射、主索引合并与回滚锚点
迁移是整个交付包里风险最高的动作，没有之一。老站点的数据往往已经积累了五六年，脏数据、重复主索引、格式不统一的日期混在一起，直接INSERT INTO ... SELECT就是一次单向事故。稳妥的做法是把迁移拆成四步：先体检、再映射、然后合并、最后比对，每一步都有独立的产物和回滚点。
4.1 迁移前体检：把脏数据先捞出来看
体检脚本的目的不是修复，是让你在动手之前知道脏数据的规模。规模超过预期就暂停，先和业务方确认处理口径，而不是让脚本自己猜。
-- 体检 1：姓名为空或含全角空格 SELECT COUNT(*) AS C FROM OLD_PAT WHERE PAT_NAME IS NULL OR PAT_NAME = '' OR PAT_NAME LIKE '% %'; -- 体检 2：同一证件号对应多个主索引（迁移后必须合并的） SELECT ID_CARD, COUNT(*) AS C FROM OLD_PAT WHERE ID_CARD IS NOT NULL AND LEN(ID_CARD) >= 15 GROUP BY ID_CARD HAVING COUNT(*) > 1; -- 体检 3：金额字段为负或为空的明细 SELECT COUNT(*) AS C FROM OLD_CHARGE WHERE AMOUNT IS NULL OR AMOUNT < 0; -- 体检 4：科室代码在字典里不存在的记录 SELECT DISTINCT DEPT_CODE FROM OLD_VISIT WHERE DEPT_CODE NOT IN (SELECT DEPT_CODE FROM DICT_DEPT);第二条是合并工作的输入，查出来的每一组都对应后面 4.3 的一次合并。第三条里的负数金额不一定是错，退费记录在老库里有时直接存负数而不是用退费标志，迁移时要按业务口径决定“转成PAY_FLAG=2的正数”还是“保留负数并标记”。第四条查出的科室代码通常是老站点已经撤销的科室，迁移时要么补进字典并标为停用，要么映射到上级科室，两种做法都要业务方签字确认。
4.2 字段映射与转换 SQL：按映射表逐列落
映射表map_v60_v65.xlsx是迁移脚本的唯一依据，不要在 SQL 里即兴发挥。核心几列的规则如下：
| 旧字段 | 新字段 | 转换规则 |
|---|---|---|
SEX（字符） | SEX（1/2/9） | 男/女/M/F 统一映射，其余归 9 |
VISIT_TIME（yyyyMMddHHmmss） | VISIT_TIME+VISIT_TIME_TXT | 双写，文本列保留原串 |
PAY_MODE（中文） | PAY_CODE | 查DICT_PAYMODE反查编码 |
AMOUNT（浮点） | AMOUNT（CURRENCY） | ROUND(x, 2)后写入 |
对应的转换语句：
-- 患者主索引迁移：SEX 归一 + 出生日期兜底 INSERT INTO PAT_MASTER (PAT_ID, PAT_NAME, SEX, BIRTHDAY, ID_CARD, CARD_NO, PHONE, CREATE_TIME, STATUS) SELECT O.PAT_ID, TRIM(O.PAT_NAME), CASE WHEN O.SEX IN ('男','M','m') THEN '1' WHEN O.SEX IN ('女','F','f') THEN '2' ELSE '9' END, -- 出生日期缺失时用 1900-01-01 占位，不允许 NULL 混进新库 IIF(ISNULL(O.BIRTHDAY), #1900-01-01#, O.BIRTHDAY), O.ID_CARD, O.CARD_NO, O.PHONE, IIF(ISNULL(O.CREATE_TIME), NOW(), O.CREATE_TIME), '1' FROM OLD_PAT O WHERE O.PAT_ID IS NOT NULL AND O.PAT_NAME IS NOT NULL;TRIM必须加，老库姓名里前导空格的记录非常普遍，不清理会导致“张伟”和“ 张伟”被当成两个人，合并阶段全部漏掉。IIF是 Jet 的条件函数，比CASE WHEN简洁，但在 SQL Server 上要换成CASE，所以schema_mssql.sql里对应的是另一份写法。出生日期用1900-01-01占位而不是NULL，是为了让后面的统计查询不用到处判空；这个占位值在报表里要单独过滤掉，否则年龄计算会算出 120 岁。
4.3 主索引合并：取存活 ID，明细改指向
同一患者多条主索引，处理原则是“保留一条、其余标记、所有引用改指”。关键是选哪条保留：不能简单取MIN(PAT_ID)，要按业务权重排序，有证件号的优先，有完整出生日期的优先，最后才比创建时间。
-- 第一步：生成合并决策表，按权重排序后每组保留第一条 SELECT ID_CARD, PAT_ID, ROW_NUMBER() OVER (PARTITION BY ID_CARD ORDER BY IIF(ID_CARD IS NULL, 1, 0), IIF(BIRTHDAY = #1900-01-01#, 1, 0), CREATE_TIME, PAT_ID) AS RN INTO TMP_MERGE FROM PAT_MASTER WHERE ID_CARD IS NOT NULL AND STATUS = '1'; -- 第二步：把非存活主索引的明细改指向存活 ID UPDATE CHARGE_DETAIL SET VISIT_ID = ( SELECT V2.VISIT_ID FROM VISIT V2 INNER JOIN TMP_MERGE M2 ON V2.PAT_ID = M2.PAT_ID AND M2.RN = 1 WHERE V2.PAT_ID = (SELECT V1.PAT_ID FROM VISIT V1 WHERE V1.VISIT_ID = CHARGE_DETAIL.VISIT_ID) ) WHERE VISIT_ID IN ( SELECT V.VISIT_ID FROM VISIT V INNER JOIN TMP_MERGE M ON V.PAT_ID = M.PAT_ID AND M.RN > 1 ); -- 第三步：被合并的主索引标记为 2，保留审计痕迹，不物理删除 UPDATE PAT_MASTER SET STATUS = '2' WHERE PAT_ID IN (SELECT PAT_ID FROM TMP_MERGE WHERE RN > 1);这里有个现实约束：如果目标库是 Access（Jet），ROW_NUMBER() OVER和SELECT INTO的窗口函数写法跑不起来，schema_mssql.sql版本才能这么写。Jet 环境下的常见做法是先把数据导到 SQL Server 的临时库做合并，合并完再导回来；或者用 ADO 在客户端逐组处理，代码量大但可控。合并步骤千万不能物理删除记录，STATUS = '2'保留痕迹，后续如果发现合并判断错了，还能反查回来。
另外，明细改指向时改的是VISIT_ID而不是PAT_ID，因为明细挂在就诊上。这一步之前必须先确认VISIT表本身已经按存活主索引改过一遍，否则子查询会拿到已经孤立的就诊号。
4.4 回滚锚点：三个数字定生死
迁移前必须记录三个数字，这是能不能回滚的唯一依据：主索引行数、就诊行数、明细金额合计（精确到分）。
-- 迁移前执行，把结果抄进值班记录 SELECT '主索引' AS K, COUNT(*) AS V FROM PAT_MASTER UNION ALL SELECT '就诊', COUNT(*) FROM VISIT UNION ALL SELECT '明细金额分', SUM(AMOUNT) * 100 FROM CHARGE_DETAIL;迁移后重跑同一段查询，三个数字必须完全一致。行数不一致通常是外键约束或数据截断导致的静默丢行；金额分不一致基本可以断定是浮点转换或四舍五入位置错了。除了这三个数字，再抽 20 条有代表性的记录人工核对：有退费的、跨月的、姓名含生僻字的、证件号是 15 位老证的。抽样核对虽然原始，但能发现自动校验查不出的字段错位问题，比如姓名灌进了地址列，这种错误行数一致、金额一致，只有人眼能看出来。
回滚本身很简单：迁移前把WI65_DATA.MDB整份复制成WI65_DATA_BAK_YYYYMMDD.MDB，回滚就是改文件名。真正的成本是回滚之后要重新走一遍体检和映射，所以迁移窗口尽量选在业务低峰，且第一次迁移必须在测试库上完整跑通。
5. 避坑与排查：五类现场故障的现象、原因与处置
老站点的问题有个共同特征：报错信息读了等于没读。下面五条是这套库在实施中出现频率最高的，按现象、原因、解决三段写，遇到时直接对号入座。
5.1 连接与文件占用类
现象一：双击打开库文件提示“不可识别的数据库格式”，但同一份文件在另一台机器上正常。
原因有两层。一是 Jet 引擎版本过低，XP 早期镜像带的msjet40.dll是 4.0.8015 之前的版本，读不了新版排序规则生成的库；二是库文件被Jet 4.0 SP8之前的引擎写入过，文件头版本号已经变了，旧引擎反向不兼容。先用dir看文件大小，如果和交付时明显不同，说明被别的程序动过。解决方式是升级 Jet 引擎到 4.0.8618 以上，然后重新分发一份原始库文件，不要试图“修复”已经被改过的文件头。
现象二：程序启动报“文件已被占用”或“无法锁定文件”，但没有任何其他窗口打开着库。
九成是上次非正常退出留下的WI65_DATA.ldb锁文件。Jet 用.ldb记录当前连接的用户，进程崩溃后文件不会自动清理，引擎看到它就认为有人在用。解决是先确认没有MSACCESS.EXE之类的进程残留，再删掉.ldb。如果.ldb反复出现，说明有程序开了连接没关，常见于报表模块用Recordset之后忘了Close，把连接池耗尽了。
5.2 编码与排序类
现象三：中文全部变成问号，或者姓名排序结果完全不符合拼音顺序。
原因是库文件的排序次序（Sort Order）建库时选的是General而不是Chinese PRC，或者工作站的区域设置不是中文（中国）。排序次序在库创建时就写死在文件头里，后期改不了。解决只能重建库：用 Jet 压缩修复工具，在选项里指定Chinese PRC排序，把数据导进新库。这个坑最恶心的地方在于，用英文排序次序建的库，中文能正常显示，只有排序和LIKE模糊查询会出错，属于“看起来没问题”的隐性问题。
5.3 数据与并发类
现象四：日结时金额合计和手工账差几分钱，逐条核对又找不出错。
原因是早期版本的金额字段用了DOUBLE，累加时产生浮点误差。单条明细看不出来，几千条汇总之后尾数就显形了。解决是把字段类型改成CURRENCY（SQL Server 侧对应DECIMAL(18,2)），迁移时统一ROUND(x, 2)，并且规定所有汇总查询在SUM之后不再做二次舍入。已经产生的历史数据要做一次全量重算，重算脚本必须跑在副本上，核对无误再回写。
现象五：两个人同时在收费窗口操作，其中一个报“无法更新，当前记录已被锁定”。
Jet 用的是页级锁，一页 4KB，同一页上的多条记录会互相阻塞。老站点的典型场景是两个窗口同时给同一个患者挂号，或者一个人在跑长报表另一个人在收费。解决分两层：应用层缩短事务，Recordset用完立刻Close，报表查询改成只读游标；结构层在VISIT_ID、CHARGE_TIME上补索引，减少全表扫描带来的长时间锁。如果站点超过五个并发窗口，老实换 SQL Server 后端，Jet 的页锁机制不适合这个量级，再怎么调都是治标。
注意：删
.ldb之前一定先确认没有活跃连接。多人共享目录下删掉别人的锁文件，会导致对方写入时数据页错乱。
6. 备份与校验：把“能恢复”变成可验证的动作
备份这件事，最怕的不是没做，而是做了但恢复不了。老站点常见的做法是每天晚上把.mdb复制一份到移动硬盘，听起来没问题，实际上复制过程中如果有连接在写，复制出来的文件可能处于半写状态，打开时报“不可识别的数据库格式”，这时候才发现三个月来的备份全是废的。
我的做法是把备份分成三层，每层都有独立的验证动作：
| 层级 | 频率 | 动作 | 验证方式 |
|---|---|---|---|
| 冷备 | 每日 22:30 | 停应用后整份复制.mdb | 校验和比对 + 试打开 |
| 增量 | 每小时 | 导出当日新增明细到文本 | 行数与源库比对 |
| 归档 | 每周 | 压缩修复后归档到离线介质 | 抽样查询验证 |
冷备的关键是“停应用”。XP 工作站上要确认所有客户端退出、.ldb文件已消失，再执行复制；复制完立刻计算校验和并与源文件比对，两边不一致就说明复制期间有写入，这次备份作废重来。每周的压缩修复不能省，Jet 库长期增删之后碎片严重，压缩一次通常能瘦身三到五成，顺带修复轻微的页损坏。
备份之外，日结报表本身就是最好的数据校验。下面这条门诊量日报的写法，顺手把三个常见错误规避掉了：
-- 门诊量日报：按科室统计人次与金额 SELECT D.DEPT_NAME, COUNT(DISTINCT V.VISIT_ID) AS 就诊人次, SUM(IIF(C.PAY_FLAG = '2', -C.AMOUNT, C.AMOUNT)) AS 净收入 FROM VISIT V INNER JOIN DICT_DEPT D ON V.DEPT_CODE = D.DEPT_CODE LEFT JOIN CHARGE_DETAIL C ON C.VISIT_ID = V.VISIT_ID WHERE V.VISIT_TIME >= #2013-08-15 00:00:00# AND V.VISIT_TIME < #2013-08-16 00:00:00# GROUP BY D.DEPT_NAME ORDER BY D.DEPT_NAME;三个细节值得说。日期区间用左闭右开，不用BETWEEN，因为BETWEEN #2013-08-15# AND #2013-08-16#会把 16 号零点整的记录算进 15 号，跨天结算时天天差一条。人次用COUNT(DISTINCT V.VISIT_ID)，因为一个就诊可能对应多条明细，直接COUNT(*)会把人次放大好几倍。退费用IIF转成负数再汇总，而不是在WHERE里过滤掉，否则净收入永远偏高。LEFT JOIN不能写成INNER JOIN，否则只挂号没收费的记录会被漏掉，那部分恰恰是欠费核查要看的数据。
从那以后我每次交付这套库，都会先把chk_05和这三个汇总数字跑一遍，把结果抄在值班记录第一页，再让业务方签字确认。备份文件不试打开一次，我是不敢说“已经备好了”的。希望帮到你。
本文还有配套的精品资源，点击获取
