简介：Wi6.5数据库（随心所欲XP工作站医疗数据库）面向医疗信息化开发者、系统维护人员及 Delphi/Interbase 技术学习者，提供一套运行于 Windows XP 工作站的医疗数据管理样本，可用于患者信息、诊疗记录等敏感数据的存储、查询、权限控制与备份恢复研究。压缩包共 967 个文件，约 28.43MB，涵盖 html 文档、dfm 窗体、pas/Delphi 源码、h/c/cpp 头文件与 C/C++ 源码、exe/dll 可执行文件与库、sql/gdb 数据库脚本及数据文件、hlp/txt 说明等，兼顾开发、部署与查阅。已有 1004 人学习下载，说明其在医疗数据库与旧版工作站维护场景中具有一定参考价值。读者可据此了解 Interbase 6.5 的表结构设计、索引与 SQL 操作、用户权限和加密机制，并对照 HL7、DICOM 等医疗信息标准梳理建模思路；也可用于复现工作站环境、排查数据异常、研究自动备份与恢复流程，为二次开发和维护旧系统提供较完整的素材。

1. 一台 XP 工作站装 wi6.5：九成失败发生在点安装之前

一台用了十几年的 XP 工作站，摆在挂号窗口下面，开机就进门诊收费和检验登记两个模块，wi6.5 数据库是它们共用的底座。这类机器不进机房，也没人日常维护，装不上就是整个诊室停摆。我经手的现场里，真正因为安装包损坏失败的不到一成，剩下的全是系统状态不对：补丁打过了头、运行库装反了序、账号被策略收走了权限，随便哪一条都能让 wi6.5 启动后静默退出，事件查看器里只留一行 1067。下面按我实际的动手顺序走一遍：先把 XP 调到可安装状态，再装服务端，然后配工作站侧的 ODBC 和 DCOM，最后给一套当天就能跑完的验证动作。手上只有一台老机器、又必须今天把它弄上线的人，按这个顺序做基本不会返工。

2. 前置环境：XP SP3、MDAC 2.8 与 .NET 2.0 的安装顺序

老机器装新软件，最怕的是"看起来能装"。XP 的版本、补丁级别、已装运行库这三样只要有一样不对，wi6.5 的安装程序照样能跑到 100%，然后在第一次启动服务时给你一个 1067，什么线索都不留。这一章做的是把地基先验一遍，验完再动手。

2.1 先确认这台机器到底是哪一版 XP

不要信机箱上贴的标签，也不要信"我一直用的是专业版"这种口头信息。三条命令任意一条能出结果就够，我习惯三条都跑一遍，把输出记在装机单上。

:: 1. 图形化版本号，弹窗里看 Service Pack 是几 winver :: 2. 系统信息里找 OS 版本和系统类型，重点看是不是 x86 systeminfo | findstr /C:"OS 名称" /C:"OS 版本" /C:"系统类型" :: 3. wmic 的输出更适合复制粘贴进装机记录 wmic os get Caption,CSDVersion,OSArchitecture /value

winver只能看个大概，真正要看的是systeminfo里的"系统类型"这一行，必须是 X86-based PC。wi6.5 这一代的医疗业务库只出过 32 位版本，装到 XP x64 上会出现存储过程调用到了、数据却没写进去的怪现象，查半天查不出所以然。另外家庭版少了一堆组策略和 DCOM 默认权限项，工作站上不要用，必须 Professional。

SP3 是下限，不是越高越好。我见过有人图省事把 IE 一路升到 8，结果内嵌的报表控件在标准模式下直接白屏，切到兼容模式才回来。补丁只打到 SP3 加关键更新，其余功能性更新一律不装，老机器的玄学问题一半来自多装的那几个补丁。

2.2 三个运行库的安装顺序：MDAC → Jet → .NET

wi6.5 的数据访问链路是 ADO 走 OLE DB，底层靠 MDAC 提供程序；本地临时表和报表缓存走 Jet 4.0；客户端外壳和部分报表控件是 .NET 2.0 写的。顺序反了会出问题——先装 .NET 再装 MDAC，后者的安装程序会判定组件已存在而跳过注册，最后表现为"提供程序未找到"。

先查现状，别盲目覆盖安装：

:: MDAC 版本，FullInstallVer 为 2.81.1132.0 说明已是 MDAC 2.8 SP1 reg query "HKLM\SOFTWARE\Microsoft\DataAccess" /v FullInstallVer :: Jet 引擎版本，4.0.9801 之后基本够用 reg query "HKLM\SOFTWARE\Microsoft\Jet\4.0\Engines\Jet 4.0" /v Version :: .NET 2.0 是否在位，Install 值为 1 表示已安装 reg query "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v2.0.50727" /v Install

输出对不上就往下一步走。MDAC 装 2.8 SP1，Jet 装 4.0 SP8，.NET 装 2.0 再补 3.5（3.5 不会覆盖 2.0，两个并存）。每次装完重启一次，不要连着装三个再重启，中间出错你分不清是谁的问题。

提示：MDAC 的安装包在 XP SP3 上经常报"已安装更新的版本"然后回滚。这是系统自带组件的版本号比安装包高导致的，不是包坏了，处理办法写在第五章。

2.3 用本地管理员把系统拉成干净状态

装之前先确认当前登录账号是不是本机管理员组成员，域账号在这台机器上经常只有普通用户权限，安装程序写注册表时会静默失败。

:: 看当前账号在不在管理员组里 net localgroup administrators :: 看本地 Administrator 的状态，装的时候用它 net user administrator

如果只有普通权限，用本地 Administrator 登录再装。装完不要图省事把 Administrator 密码留空，也不要把业务账号塞进管理员组——wi6.5 的客户端会继承当前登录用户的 DCOM 权限，权限给太大反而在后续做权限收紧时没法回退。

然后是干净启动。msconfig里把启动项全部取消勾选，第三方安全软件临时退出（装完再加白名单），系统还原如果开着，装之前手动打一个还原点，或者直接用镜像工具做一份系统盘备份——这是唯一的后悔药，比任何卸载脚本都靠谱。

最后是区域设置，这一步最容易被跳过，也最容易在装完之后反咬一口：控制面板 → 区域和语言选项 → 自定义 → 日期，短日期格式改成yyyy-MM-dd，长时间格式改成HH:mm:ss，不要留yy-M-d这种。wi6.5 里大量按字符串比较日期的查询，格式一变，查询要么返回空结果集，要么直接抛数据类型转换错误。

3. 服务端安装：wi6.5 的目录划分、14330 端口与登录模式

前置环境过了，才轮到安装包。这一步真正要决策的只有三件事：东西放哪、端口用哪个、服务用什么账号跑。三件事在安装向导里都有默认值，而默认值几乎不适合医疗工作站这种一机多用的场景。

3.1 三层目录分开：程序、数据、日志各走各的

默认安装会把程序和数据塞进同一个目录，甚至塞进C:\Program Files。这在只有一块盘的老机器上看着省事，出事的时候很要命：日志写满把数据盘撑爆、程序目录被误删带着数据一起没、备份脚本没法只备份数据目录。

我一般这么分：

:: 目录一次性建好，避免安装程序自己创建时带上奇怪权限 mkdir D:\WI65\BIN mkdir D:\WI65\DATA mkdir D:\WI65\LOG mkdir E:\WI65\BAK :: 确认路径里没有中文和空格，返回的应该是纯 ASCII 路径 echo %ProgramFiles%

路径里有中文或者空格，某些老版本的报表引擎解析短路径名时会截断，表现是打印预览空白。这一点不要挑战，老老实实全用英文目录。

3.2 实例端口：1433 该不该让

wi6.5 默认实例按惯例走 1433。问题是这台 XP 上往往还跑着别的老系统——检验科的仪器接口、旧版的影像归档，谁先起来谁占住 1433，后来者启动时报"无法绑定端口"，事件日志里是一条 10048。

我的做法是：只要这台机器上不止一个数据库实例，就把 wi6.5 挪到 14330，并且在客户端配置里写死端口，不依赖 SQL Browser 服务去做实例名解析（XP 上那个 UDP 1434 的解析在跨网段时经常不靠谱）。

配置文件一般长这样，安装向导里能填的都在这里，填完记得重启服务：

[Database] ; 服务端地址，单机部署写 127.0.0.1，工作站连服务端写内网 IP Server = 192.168.10.21 ; 实例名，命名实例必须和安装时填的一致 Instance = WI65 ; 固定端口，避免和机器上其他实例抢 1433 Port = 14330 ; 业务库名，安装时如果改过这里要同步 Database = WIDB ; 业务账号，不要用 sa User = wi_user Password = ******** ; 连接池开关，工作站并发不高时开着能少很多重连 Pooling = 1

改完端口先确认监听起来了，再继续往下：

:: 看 14330 有没有在监听，LISTENING 才算成功 netstat -ano | findstr :14330 :: 顺带确认没有别的进程占着 1433 netstat -ano | findstr :1433

netstat输出里 PID 那一列记下来，可以在任务管理器里对上是哪个进程，排查端口冲突时这列最有用。

3.3 登录模式与服务账号：别用 sa，也别用本地系统账号

安装向导里"身份验证模式"这一页，选混合模式，然后立刻给 sa 设一个强密码并记在密码管理里，不要留空。空密码的 sa 在内网里是最常见的翻车点，一台机器中招，整个科室的数据库都能被读走。

服务账号我一般单独建一个，只给普通用户权限，然后把它加进"作为服务登录"的策略里：

:: 建一个专用服务账号，密码永不过期 net user wi_svc Change_This_Pwd_2024 /add /comment:"wi6.5 service account" /expires:never :: 只加进 Users 组，不要加 administrators net localgroup Users wi_svc /add :: 把服务改成用这个账号跑 sc config "WI65DB" obj= ".\wi_svc" password= "Change_This_Pwd_2024" :: 回读一遍配置，确认 SERVICE_START_NAME 已改 sc qc "WI65DB"

sc config里obj=后面必须是一个空格再接引号，写成obj=".\wi_svc"会报参数错误，这个坑我踩过不止一次。改完账号之后要给数据目录重新授权，否则服务能起来但写不进数据——XP 上直接在文件夹属性的安全选项卡里把wi_svc加进去，给"修改"权限，不要给"完全控制"。

4. 工作站侧配置：32 位 ODBC 数据源、DCOM 权限与 hosts 固定

服务端起得来，只是证明服务端自己没问题。真正让业务跑起来的是工作站这一侧，而这一侧的配置项分散在三个完全不同的地方，缺一个就是连不上。

4.1 建 DSN 只能走 odbcad32

XP 是纯 32 位系统，控制面板里那个"数据源 (ODBC)"指向的就是 32 位版本，直接点开就行。如果这台机器是 64 位系统上跑兼容模式，一定要手动去C:\WINDOWS\SysWOW64\odbcad32.exe，从控制面板进的是 64 位版本，建出来的 DSN 业务程序根本读不到。

步骤按这个顺序走：

1. 打开C:\WINDOWS\System32\odbcad32.exe
2. 切到"系统 DSN"选项卡，不要建在"用户 DSN"下——服务方式启动的程序读不到用户 DSN
3. 添加驱动，选服务端对应的那一个，名称填WI65
4. 服务器填内网 IP，勾掉"使用可信连接"，填业务账号和密码
5. 下一步里把默认数据库改成WIDB，测试连接

建完回读一遍注册表，确认写进去了：

:: 列出所有系统 DSN，能看到 WI65 这一条才算成功 reg query "HKLM\SOFTWARE\ODBC\ODBC.INI\ODBC Data Sources" :: 看这个 DSN 具体连的是哪台机器、哪个库 reg query "HKLM\SOFTWARE\ODBC\ODBC.INI\WI65"

第二条命令的输出里重点看Server和Database两个值，我遇到过在向导里改了服务器但没点"下一步"直接点完成的情况，DSN 建出来了，连的还是上一次填的地址，测试永远超时。

4.2 DCOM 里要动的是三处，不是一处

医疗业务系统里，客户端进程调用服务端的组件，走的是 DCOM。默认权限下，普通用户能访问但不能启动，表现是客户端一闪而过，事件日志里一条 10009。要改的地方有三处，只改一处不够。

:: 打开组件服务配置界面 dcomcnfg :: 顺手把默认访问权限导出来看一眼，排查时比对用 reg query "HKLM\SOFTWARE\Microsoft\Ole" /v DefaultAccessPermission

在dcomcnfg里依次改：

• 组件服务 → 计算机 → 我的电脑 → 属性 → 默认属性：把"在此计算机上启用分布式 COM"勾上
• 同一窗口 → 默认 COM 安全 → 访问权限：加入NETWORK SERVICE和Everyone，权限勾"本地访问"
• 同一窗口 → 默认 COM 安全 → 启动和激活权限：加入业务账号，勾"本地启动""本地激活"

改完这三处，再找人：组件服务 → 计算机 → 我的电脑 → DCOM 配置 → 找到 wi6.5 对应的那个应用条目 → 属性 → 身份选项卡，选"交互式用户"或者指定刚才那个服务账号。这一步选错，前面的权限全白配。

注意：改完 DCOM 权限必须重启一次机器，只重启服务不生效。这是老版本 COM 组件的老毛病，别在这上面省时间。

4.3 hosts 写死，防火墙放行

最后一件事是把名字解析固定下来。医疗内网里经常有同名的工作组或者残留的 NetBIOS 缓存，客户端用主机名连服务端时，有时候解析到一台已经下线的旧机器上，表现为"时而能连时而连不上"，最难查的那种。

:: 把服务端名字写死，避免 NetBIOS 解析飘 echo 192.168.10.21 wiserver >> C:\WINDOWS\system32\drivers\etc\hosts :: 确认写进去了 type C:\WINDOWS\system32\drivers\etc\hosts :: 放行 14330 端口，XP 自带的防火墙走 netsh netsh firewall set portopening TCP 14330 "WI65"

hosts 文件如果写不进去，先看是不是只读属性，XP 上这个文件被安全软件锁住的情况很常见，临时退出安全软件再写。端口放行之后，从工作站上telnet 192.168.10.21 14330试一下，能连上说明网络层通了，剩下的就都是应用层的事。

5. 排查记录：五个把 wi6.5 卡在启动阶段的现场

安装过程中会报错的地方就那么几处，报出来的错还都长得很像。下面这五条是我在不同机器上反复遇到的，按"现象 → 原因 → 解决"记，遇到对得上的直接照着做。

5.1 服务启动后立刻停止，报 1067

现象：服务管理器里点启动，进度条走两秒，弹出"错误 1067：进程意外终止"。事件日志里除了 1067 没有更多信息。

原因：九成是数据目录权限不够，服务账号能读目录但写不进文件，初始化时打不开数据文件就直接退出。剩下一成是端口被占，绑定失败。

解决：先排除端口——netstat -ano | findstr :14330，如果已有进程占着，改端口或者停掉那个进程。端口没问题就查权限，把wi_svc加到D:\WI65\DATA和D:\WI65\LOG的安全选项卡里，给"修改"权限，重启服务。还不行就手动用wi_svc账号登录一次桌面，跑一下D:\WI65\BIN下的主程序，报错信息会比服务方式详细得多。

5.2 客户端报 10009，或者"RPC 服务器不可用"

现象：服务端一切正常，工作站点客户端图标之后就没了，事件日志里是 10009 或者"RPC 服务器不可用"。

原因：DCOM 的三处权限没配全，或者配了但没重启。还有一种情况是 XP 没打 RPC 相关补丁，SP2 上这个错特别高频。

解决：按 4.2 的三处权限逐个确认，配完重启整机。如果补丁级别还在 SP2，先升到 SP3。另外用dcomcnfg的时候注意，改的是"我的电脑"这个节点，不是某个具体应用的属性页，改错地方的现象是配置看着改了但一点效果都没有。

5.3 MDAC 安装回滚，提示已安装更新的版本

现象：双击 MDAC 2.8 SP1 安装包，进度条走完弹一句"该产品已安装更新版本"，然后回滚，注册表里的FullInstallVer一点没变。

原因：XP SP3 自带的 MDAC 版本号比独立安装包里的高，安装程序的版本判定直接拒绝。这是正常行为，不是包坏了。

解决：先reg query确认FullInstallVer已经 ≥ 2.81.1132.0，是的话直接跳过，不用装。如果确实是低版本又装不上，走dasetup.exe /q静默参数强装，或者用系统盘里的组件修复。千万别为了装它去卸载系统组件，那台机器多半就起不来了。

5.4 查询报"数据类型转换失败"或者日期越界

现象：客户端能登录，菜单能点开，一查当天的挂号记录就报错，换个日期查又能查出来。

原因：系统短日期格式不是yyyy-MM-dd。wi6.5 里有大量拼字符串的查询，2024-3-5和2024-03-05在字符串比较里是两个东西，边界日期上就会翻车。

解决：控制面板 → 区域和语言选项 → 自定义 → 日期，短日期改成yyyy-MM-dd，长日期和时间一并改掉，重启客户端。改完顺手把服务器的区域设置也统一，两边不一致时同一个查询在两台机器上结果不同，这种问题查起来能耗掉一整天。

5.5 报表能预览，打印出来空白或者乱码

现象：业务数据都对，报表点预览也正常，一按打印，纸出来是空的，或者中文变成方块。

原因：默认打印机不是本地打印机，或者服务端没有装报表需要的字体。XP 上的报表引擎取的是默认打印机的纸张设置，默认打印机指向网络打印机而网络又不通时，直接输出空白。

解决：把一台本地打印机设为默认，纸张固定成 A5 或者报表模板要求的规格。字体缺失就补装常用中文字体，装完重启一次客户端。这一条不影响数据正确性，但会卡住交付，装完一定要真打一张。

6. 交付前验证：用四步把 wi6.5 从能启动跑成能读写

服务起来、客户端能登录，只能说明装完了，不能说明能交付。我交付前的固定动作是四步，每一步都有一个明确的通过标准，少一步都不签字。

第一步看服务和端口。sc query "WI65DB"里 STATE 必须是 RUNNING，netstat -ano | findstr :14330必须有一行 LISTENING。第二步看数据库层，用业务账号而不是 sa 去连，能连上才说明账号权限配对了。

:: 第一步：服务状态与端口监听 sc query "WI65DB" netstat -ano | findstr :14330 :: 第二步：用业务账号做一次最小连接测试 osql -S 192.168.10.21,14330 -U wi_user -P 你的密码 -d WIDB -Q "SELECT 1"

osql那行的-S后面是"地址,端口"，中间是英文逗号，写成中文逗号会连到默认实例上去，测试就白做了。返回1说明账号、库名、端口三样全对。

第三步是真实读写往返，不要只做查询。新增一条挂号记录、查出来、改一下状态、再作废删掉，全程用业务账号走客户端界面，不要用管理工具直接改表——用工具改表验证不出触发器、约束和权限的问题。第四步打一张报表，看纸张和字体。

四步里最容易被跳过的是最后一步，也是最容易在交付第二天出问题的一步。数据全对、报表打不出来，窗口照样没法用。

从那以后我每次装完 wi6.5，不管多赶时间，第五步的读写往返和打印这两项都强制走一遍，宁可多花十分钟，也不想第二天早上七点半接到窗口打来的电话。希望这套流程能帮到你。

本文还有配套的精品资源，点击获取