企业官网建设流程全解析

简介：《瑞美4.79客户端 单机版》面向医疗机构检验科技术人员、医生及信息化维护人员，提供可独立运行的LIS客户端环境，用于样本采集、检测信息录入、结果查询、报告生成和质控管理等日常业务，适合需要本地单机部署或与瑞美LIS系统交互的场景。资源以rar压缩包分发，体积约133.27MB，文件总数及内部类型明细上游暂未提供，使用前应核对Windows兼容性、内存和硬盘空间等运行条件。已有1815人浏览学习，具备一定关注度。读者可借此熟悉LIS业务链路及样本管理、检验项目、报告模板、数据同步与安全传输等模块，为系统部署、操作和问题排查提供参考。

1. 单机版不是"装完就能用"：瑞美 4.79 客户端落地前要先摸清的三件事

压缩包解开，目录里横着一个 setup.exe 和几个看不出用途的子目录，这是大多数人第一次接触瑞美4.79客户端 单机版 时的场景。双击、下一步、完成，看起来十分钟能收工，但单机版把原本属于服务器的那一层全压进了本机——数据库实例、附件目录、打印模板、运行库，全靠这台机器自己兜。真正让人翻车的从来不是安装向导，而是装完之后：库实例有没有起来、连接串指向哪个路径、附件默认落在哪块盘。这篇按拆包体检、本地库落地、备份还原、踩坑处置、升级前校验五段走，适合要在一台机器上把系统跑稳的人，也适合接手别人装好的机器、接手就要排查的人。

2. 拆安装包与装机体检：setup 背后藏的四个目录和三处依赖

拿到一个客户端安装包，先别急着双击。单机版客户端的安装包结构通常有规律：根目录一个引导程序，旁边跟着 redist（运行库）、data 或 db（建库脚本与初始数据）、template（打印模板）、help 几个子目录。这几个目录的存在与否，直接决定你后面要不要手动补运行库、要不要手工执行建库脚本。摸清楚它们，比记住安装向导上那几页选项有用得多。

2.1 先判断打包器，再决定用什么方式拆

安装包由哪种工具打包，决定了它支持哪些命令行参数、能不能静默安装、能不能解出内部文件。常见的是 Inno Setup、NSIS、InstallShield、WiX 这几种，判断方式很土但很准：在二进制里找特征字符串。Windows 上没有 strings 命令，用 PowerShell 读字节筛 ASCII 就行。

# 读取安装包前 2MB 字节，筛出可打印 ASCII，匹配打包器特征串 $path = "D:\pkg\setup.exe" $bytes = [System.IO.File]::ReadAllBytes($path)[0..2MB] $ascii = -join ($bytes | ForEach-Object { if ($_ -ge 32 -and $_ -le 126) { [char]$_ } else { "`n" } }) $ascii -split "`n" | Where-Object { $_ -match "Inno Setup|Nullsoft|InstallShield|WiX Toolset|MSI" } | Select-Object -Unique

这段脚本只读前 2MB，是因为打包器标识通常写在文件头部的资源段或字符串表里，读全量既慢又吃内存。2MB这个上限对绝大多数安装包够用，如果什么都没匹配到，把范围放大到 8MB 再试一次。匹配到Nullsoft说明是 NSIS，静默参数一般是/S；匹配到Inno Setup则是/VERYSILENT /NORESTART；两者都没有、但文件能被 7-Zip 直接打开列出内容，那多半是自解压壳，可以直接解出来看目录结构。这一步的价值在于：你能在不动系统的前提下，先把 redist 和 db 目录里的东西看一遍。

2.2 装机前的六项体检，别等报错才回头查

单机版客户端对环境的依赖集中在六处：系统版本与位数、系统盘余量、UAC 级别、已装运行库、同名数据库实例、被占用的端口。这六项里任何一项不满足，安装过程可能一路绿灯，但首次启动就给你一个没有上下文的弹窗——这种黑匣子式报错最耗时间。我一般的做法是先跑一遍体检脚本，把结果落到一个文本文件里，出问题的时候直接对着看。

# 装机体检：输出系统、磁盘、UAC、运行库、数据库实例、端口占用情况 $report = "D:\install-check-$(Get-Date -f yyyyMMdd-HHmm).txt" "=== OS ===" | Out-File $report Get-CimInstance Win32_OperatingSystem | Select-Object Caption, Version, OSArchitecture, LastBootUpTime | Format-List | Out-File $report -Append "=== Disk ===" | Out-File $report -Append Get-PSDrive -PSProvider FileSystem | Select-Object Name, @{n='FreeGB';e={[math]::Round($_.Free/1GB,1)}}, @{n='UsedGB';e={[math]::Round($_.Used/1GB,1)}} | Format-Table -AutoSize | Out-File $report -Append "=== UAC ===" | Out-File $report -Append (Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System") | Select-Object EnableLUA, ConsentPromptBehaviorAdmin | Format-List | Out-File $report -Append "=== .NET Framework ===" | Out-File $report -Append (Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full" -ErrorAction SilentlyContinue) | Select-Object Version, Release | Format-List | Out-File $report -Append "=== DB Services ===" | Out-File $report -Append Get-Service | Where-Object { $_.Name -match "MSSQL|SQLBrowser|MySQL|Firebird" } | Select-Object Name, Status, StartType | Format-Table -AutoSize | Out-File $report -Append "=== Port 1433/1434 ===" | Out-File $report -Append Get-NetTCPConnection -State Listen -ErrorAction SilentlyContinue | Where-Object { $_.LocalPort -in 1433,1434 } | Select-Object LocalAddress, LocalPort, OwningProcess | Format-Table -AutoSize | Out-File $report -Append Write-Host "报告已写入 $report"

脚本分六段，每段对应一项体检。Get-PSDrive那段重点看系统盘剩多少——单机版的库文件、日志文件、附件默认都在系统盘，低于 20GB 就要提前规划迁移，别等库撑爆了再挪。UAC 那段的EnableLUA如果是 1 且ConsentPromptBehaviorAdmin为 2，说明默认会弹提权框，安装和后续改配置文件都可能被拦，建议临时降到提示级别再操作，装完恢复。.NET Framework的Release值比Version更能反映实际补丁级别，客户端启动即崩、事件日志里出现0xc0000135这类错误码，八成就是这一项不达标的锅。数据库服务那一段是给自己确认：这台机器上是不是已经有一个同名实例，装了别家软件留下的 SQL Server Express 实例，端口和实例名都可能撞。

2.3 目录结构与配置文件的读取顺序

安装完成后，先别点快捷方式。把安装目录展开看一遍，通常长这样：

配置文件的位置比内容更值得先搞清楚，因为这类客户端常见的读取顺序是：程序目录下的配置 → 用户目录下的配置 → 注册表里的路径项，后读到的覆盖先读到的。所以在程序目录里改了连接串却没生效，很可能是用户目录下还有一份同名配置在起作用。判断方法很简单：改一个显眼的项（比如把超时改成 1 秒），启动看行为有没有变化，没变化就说明改的那份没被读到。这一步花五分钟，能省掉后面半小时的"改了没用"。

3. 把本地库跑起来：实例、认证模式与连接串的三处关键改动

单机版客户端的本地存储有两种形态，先分清再动手，方向错了后面全是白工。一种是文件型，安装目录或数据目录里能看到.mdb、.accdb、.db、.fdb这类单文件，客户端直连文件，没有服务进程；另一种是实例型，机器上跑着一个数据库服务（常见是 SQL Server Express 的命名实例），客户端通过连接串访问。判断方法：先看服务列表里有没有数据库服务，再看安装目录里有没有单文件库。两者都有的话，以配置文件里的连接串为准。

3.1 实例型库的初始化：认证模式与端口两件事

如果确认是实例型，第一次启动前要确认三件事：实例是否已启动、认证模式是否允许客户端用的账号登录、端口是否固定。SQL Server Express 默认装成命名实例，走动态端口，客户端如果按固定端口连就会时通时不通。查认证模式和实例名的语句很短：

-- 查实例名、版本、认证模式（1 = 仅 Windows 认证，0 = 混合认证） SELECT SERVERPROPERTY('InstanceName') AS InstanceName, SERVERPROPERTY('ProductVersion') AS ProductVersion, SERVERPROPERTY('IsIntegratedSecurityOnly') AS WindowsAuthOnly, @@VERSION AS FullVersion;

IsIntegratedSecurityOnly返回 1 意味着只允许 Windows 身份验证，客户端如果配的是数据库账号密码，连上去必然报登录失败。改成混合认证要动注册表并重启服务，顺序不能反：

# 将默认实例改为混合认证模式，然后重启服务生效 $key = "HKLM:\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL15.SQLEXPRESS\MSSQLServer" Set-ItemProperty -Path $key -Name LoginMode -Value 2 -Type DWord Restart-Service -Name "MSSQL`$SQLEXPRESS" -Force # 启用并启动 SQL Browser，命名实例靠它解析 Set-Service -Name "SQLBrowser" -StartupType Automatic Start-Service -Name "SQLBrowser"

LoginMode的值 2 表示混合认证，1 表示仅 Windows 认证，改完必须重启实例服务才生效，只改注册表不重启是最常见的"改了没反应"。注册表路径里的MSSQL15.SQLEXPRESS要按实际版本替换，MSSQL15对应的是 SQL Server 2019 系列的内部版本号，装的是别的版本就得换成对应的段。SQLBrowser服务的作用是让客户端用"主机名\实例名"的写法解析到实际端口，命名实例没启动这个服务，客户端就只能靠猜端口，表现是偶尔能连、多数时候超时。这一步做完，再用sqlcmd验一次连通性：

# 用 Windows 认证连命名实例，执行一条最小查询验证链路 sqlcmd -S "localhost\SQLEXPRESS" -E -C -Q "SELECT DB_NAME() AS CurrentDB, SUSER_NAME() AS LoginName;" # 用数据库账号验证混合认证是否真的开了 sqlcmd -S "localhost\SQLEXPRESS" -U app_user -P "YourPassword" -C -Q "SELECT 1;"

-E走 Windows 集成认证，-C是信任服务器证书（本地自签证书场景下不加这个参数会报证书链错误），-Q直接执行语句后退出。两条都要跑通：第一条通、第二条不通，说明混合认证没生效或者账号没建；两条都不通，问题在实例没起或端口没开。这个分层判断比盯着客户端报错猜要快得多。

3.2 连接串与附件路径：配置文件里必须改的两处

连接串通常写在config目录下的 xml 或 ini 文件里。改之前先备份原文件，这不是形式主义——单机版的配置项往往没有图形界面入口，改错了只能靠还原文件回退。

<!-- 客户端主配置：连接串与附件根目录两块是装机后必改项 --> <configuration> <connectionStrings> <!-- Data Source 用 主机名\实例名，不用 IP；AttachDbFilename 留空由服务端管理 --> <add name="MainDb" connectionString="Data Source=localhost\SQLEXPRESS;Initial Catalog=remi_main;User ID=app_user;Password=YourPassword;Connect Timeout=15;Pooling=true;" providerName="System.Data.SqlClient" /> </connectionStrings> <appSettings> <!-- 附件根目录改到数据盘，避免系统盘被单据附件撑满 --> <add key="AttachRoot" value="D:\DataRoot\attach\" /> <add key="BackupRoot" value="D:\DataRoot\backup\" /> <add key="LogLevel" value="Info" /> </appSettings> </configuration>

Data Source优先写"实例名"而不是 IP，因为动态端口下 IP 加端口很容易在服务重启后失效。Connect Timeout默认 15 秒对本地库偏长，出问题的时候会让你误以为是卡死，可以先调到 5 秒做排查，稳定后再改回来。AttachDbFilename这种直接挂文件的写法在单机版里偶尔能见到，它的问题是文件被客户端独占，备份脚本一读就报占用，能改成服务端管理的库就改。AttachRoot和BackupRoot两个路径一定要落在非系统盘，并且路径结尾带反斜杠——不少客户端是直接做字符串拼接的，少了这个斜杠就会拼出D:\DataRoot\attach20240101这种畸形路径，附件写入直接失败。

提示：改配置文件前先把整个 config 目录复制一份到带日期的备份目录，改完启动验证通过再删。这类客户端的配置项没有校验机制，写错一个字符的后果往往是启动即闪退，且不留日志。

3.3 库文件默认位置的迁移

实例型库有个默认行为：新建数据库的文件落在实例安装时设定的默认目录，通常在系统盘的Program Files下面。单机版跑上一年半载，库文件和日志加起来几十 GB 不稀奇，系统盘告急之后才想起来挪，就得停机、分离、搬文件、再附加，风险比一开始就规划好高得多。装机阶段就把默认数据目录改到数据盘，代价只有一个改注册表动作：

-- 查当前实例的默认数据与日志目录 SELECT SERVERPROPERTY('InstanceDefaultDataPath') AS DefaultDataPath, SERVERPROPERTY('InstanceDefaultLogPath') AS DefaultLogPath;

-- 修改默认数据目录（需重启实例生效） USE master; EXEC xp_instance_regwrite N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'DefaultData', REG_SZ, N'D:\SQLData'; EXEC xp_instance_regwrite N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'DefaultLog', REG_SZ, N'D:\SQLLog';

xp_instance_regwrite写的是实例级注册表项，改完重启服务，之后新建的库才会落到新目录，已有库不会自动搬家。已有库要迁移，走"备份—还原到新路径—验证—删除旧库"的顺序，别用直接拷.mdf的方式，文件头里记着原路径，拷过去附加时十有八九报"无法打开物理文件"。这个坑后面还会单独说。

4. 备份与还原：库、附件、配置三类资产要分开处理

单机版最容易出的事故不是装不上，而是"数据在，但用不了"。原因通常是备份只做了数据库，附件目录和配置文件没跟着走；或者备份做了、还原没演练过，真出事的时候发现还原脚本里的路径对不上。备份这件事，把资产分类清楚比脚本写得多漂亮更重要。

4.1 三类资产的备份边界

三类资产的关键点是时间点要一致。库备份在 23:00，附件目录 02:00 才同步，中间三个小时新增的单据在库里没有、在附件里也没有，这种不一致在还原后表现为"单据列表里有记录，点开提示附件不存在"。稳妥的做法是把库备份和附件同步放在同一个脚本里串行执行，中间不接受新的写入——单机版有个便利条件，可以让客户端退出后再跑备份，不必考虑在线一致性。

# 单机版三类资产一体化备份：库备份 -> 附件同步 -> 配置归档 param( [string]$Instance = "localhost\SQLEXPRESS", [string]$Database = "remi_main", [string]$BackupRoot = "D:\DataRoot\backup", [string]$AttachRoot = "D:\DataRoot\attach", [string]$ConfigDir = "C:\Program Files\RemiClient\config", [int]$KeepDays = 14 ) $stamp = Get-Date -Format "yyyyMMdd-HHmmss" $target = Join-Path $BackupRoot $stamp New-Item -ItemType Directory -Path $target -Force | Out-Null # 1) 数据库完整备份，压缩开启 $bak = Join-Path $target "$Database.bak" $sql = "BACKUP DATABASE [$Database] TO DISK = N'$bak' WITH INIT, COMPRESSION, CHECKSUM, STATS = 10;" sqlcmd -S $Instance -E -C -b -Q $sql if ($LASTEXITCODE -ne 0) { throw "数据库备份失败，退出码 $LASTEXITCODE" } # 2) 附件目录镜像同步，/MIR 会删除目标端多余文件，慎用；首次建议先 /L 试跑 robocopy $AttachRoot (Join-Path $target "attach") /MIR /R:2 /W:5 /LOG+:(Join-Path $target "robocopy.log") | Out-Null if ($LASTEXITCODE -ge 8) { throw "附件同步失败，robocopy 退出码 $LASTEXITCODE" } # 3) 配置与模板归档 Compress-Archive -Path $ConfigDir -DestinationPath (Join-Path $target "config.zip") -Force # 4) 清理超过保留天数的备份目录 Get-ChildItem $BackupRoot -Directory | Where-Object { $_.CreationTime -lt (Get-Date).AddDays(-$KeepDays) } | Remove-Item -Recurse -Force

脚本的四个阶段对应四类动作。-b让 sqlcmd 在出错时返回非零退出码，没有这个参数，备份失败脚本也会继续往下走，最后你得到一个"看起来成功"的空备份。COMPRESSION和CHECKSUM在单机版场景下成本很低，前者省一半磁盘，后者能在备份时就发现页损坏，比还原时才发现强。robocopy的退出码要按区间判断：0～7 是正常（有文件复制、有跳过都算正常），8 以上才是失败，直接判断-ne 0会把正常情况误判成失败。/MIR是镜像模式，会删除目标端源端没有的文件，第一次跑建议换成/E并且先加/L（只列出不执行）确认一遍，确认无误再正式跑。

注意：备份脚本本身要放进计划任务，但计划任务用的账号必须有实例的备份权限和目标目录的写权限。用 SYSTEM 账号跑、结果实例只授权了当前登录用户，表现是手工跑成功、定时跑静默失败，日志里只有一行权限拒绝。

4.2 还原演练：WITH MOVE 是绕不过去的一步

备份没演练过等于没备份。还原到一个临时库名做验证，是最省事的演练方式，重点在于RESTORE语句必须带WITH MOVE，把逻辑文件名映射到当前机器的实际路径上。

-- 先看备份文件里的逻辑文件名，RESTORE FILELISTONLY 不改动任何数据 RESTORE FILELISTONLY FROM DISK = N'D:\DataRoot\backup\20240601-230000\remi_main.bak'; -- 按上一步查到的逻辑名做重定位还原，库名加 _verify 后缀避免影响生产库 RESTORE DATABASE [remi_main_verify] FROM DISK = N'D:\DataRoot\backup\20240601-230000\remi_main.bak' WITH MOVE N'remi_main' TO N'D:\SQLData\remi_main_verify.mdf', MOVE N'remi_main_log' TO N'D:\SQLLog\remi_main_verify_log.ldf', REPLACE, STATS = 10;

RESTORE FILELISTONLY只读备份文件的元数据，安全无副作用，返回的 LogicalName 一列就是要填进MOVE的名字。这一步不能跳，逻辑名是建库时定的，跟你现在的库名不一定一致，猜错了就报"逻辑文件未找到"。REPLACE允许覆盖同名库，演练时配合_verify后缀用，避免手滑覆盖生产库。还原完成后跑一遍行数比对，比看"还原成功"的提示有用：

-- 还原后行数比对：生产库与验证库的关键表计数应完全一致 SELECT 'bill_main' AS TableName, COUNT(*) AS Cnt FROM remi_main.dbo.bill_main UNION ALL SELECT 'customer', COUNT(*) FROM remi_main.dbo.customer UNION ALL SELECT 'bill_main', COUNT(*) FROM remi_main_verify.dbo.bill_main UNION ALL SELECT 'customer', COUNT(*) FROM remi_main_verify.dbo.customer;

计数一致只说明数据落全了，还要抽一张单据打开看附件能不能加载——附件路径是写在库里的绝对路径，换机器后路径前缀变了，库里的记录还指着老路径，这就是下一章要说的坑。

5. 避坑排查：五类翻车现场的现象、成因与处置

单机版的问题有个共同特征：报错信息极短，指向性极差。同一句"操作失败"，可能是运行库缺失，也可能是附件目录没权限。下面五条是按出现频率排的实际记录，每条都按现象、成因、处置三段写，遇到类似表现可以对着排查，比从头猜快。

5.1 能登录，一打印就提示找不到报表组件

现象很典型：主界面正常，单据能查能改，点打印预览的瞬间弹一个没有错误码的提示框，或者干脆整个客户端退出。成因多数在打印组件这一层——这类客户端的报表模块通常依赖独立的报表引擎和一组字体，安装包里的 redist 目录如果没装全，主程序照跑，打印链路一调就断。另一种情况是远程桌面或精简版系统裁剪了打印后台服务，Print Spooler没起来，报表引擎初始化时拿不到默认打印机就崩。

处置分三步走。先确认打印后台服务状态：Get-Service Spooler看是否 Running，StartType 是否为 Automatic。再确认 redist 目录里的运行库是否都装过，重点看报表引擎对应的运行库和字体包，字体缺失时报表能预览但导出 PDF 会乱码或空白。最后看事件查看器的应用程序日志，筛选来源为主程序 exe 的错误条目，0xc0000135（缺 DLL）和0xc000041d（未处理异常）这两类错误码指向完全不同的方向，别混着查。

# 打印链路排查：后台服务、默认打印机、报表依赖 DLL 是否存在 Get-Service Spooler | Select-Object Name, Status, StartType Get-CimInstance Win32_Printer | Where-Object { $_.Default -eq $true } | Select-Object Name, DriverName, PortName $appDir = "C:\Program Files\RemiClient" "crpe32.dll","rptengine.dll" | ForEach-Object { $p = Join-Path $appDir $_ [pscustomobject]@{ Dll = $_; Exists = (Test-Path $p) } }

Win32_Printer里Default为真的那条如果为空，说明没有设置默认打印机，报表引擎初始化会失败。DLL 检测那段要把文件名换成实际安装目录里看到的报表相关 DLL，Test-Path返回 False 就说明安装不完整，重装 redist 比手工拷 DLL 可靠得多——手工拷进去往往会连带缺一串依赖。

5.2 用了三个月，启动从五秒变成四十秒

现象是渐进的，一开始只是启动慢一点，后来越来越明显，最后点开单据列表要转圈十几秒。成因基本锁定在库文件和日志的膨胀上：单机版默认把库建成完整恢复模式，日志文件只增不减，加上附件表里存了二进制内容或者大量索引碎片，查询计划一步步走偏。系统盘剩余空间低于 10% 之后，Windows 的文件系统本身也会拖慢，两个因素叠在一起。

处置顺序是先看体积再动手。查库和日志的占用：

-- 查各库数据文件与日志文件占用，定位膨胀来源 SELECT DB_NAME(database_id) AS DbName, name AS LogicalName, type_desc, CAST(size * 8.0 / 1024 AS DECIMAL(10,1)) AS SizeMB, CAST(FILEPROPERTY(name,'SpaceUsed') * 8.0 / 1024 AS DECIMAL(10,1)) AS UsedMB FROM sys.master_files ORDER BY SizeMB DESC;

日志文件type_desc为LOG的那行如果 SizeMB 远大于 UsedMB，就是日志没截断。单机版场景下没有必要用完整恢复模式，改成简单恢复并做一次日志收缩，能立刻释放空间：

ALTER DATABASE [remi_main] SET RECOVERY SIMPLE; DBCC SHRINKFILE (N'remi_main_log', 512);

SHRINKFILE的第二个参数是目标大小（MB），给 512 是留出余量，别直接缩到 1MB——下次业务高峰日志暴涨又会反复扩张，文件碎片反而更多。改成简单恢复模式之后，日志在检查点后自动截断，代价是失去时间点恢复能力，对单机版来说这个代价可以接受，前提是第四章那套备份脚本在正常跑。碎片问题用sys.dm_db_index_physical_unit看平均碎片率，超过 30% 再重建，别没事就重建一遍，重建期间的锁等待在单机上感受很明显。

5.3 换机还原后单据都在，附件全变红叉

现象是数据完整、列表正常，点开任何一张带附件的单据都提示文件不存在。成因有两个，一是备份时只备了库没备附件目录，二是备了附件但库里的路径记录还是老机器的绝对路径。第二种更常见，因为附件路径通常以完整路径字符串存在附件表里，换了盘符或者换了机器名，前缀就对不上。

处置要分两步，先确认文件是否真的存在，再决定是改路径还是补文件：

-- 查附件表里记录的路径前缀分布，确认是否还是老机器路径 SELECT LEFT(file_path, 24) AS PathPrefix, COUNT(*) AS Cnt FROM dbo.attach_file GROUP BY LEFT(file_path, 24) ORDER BY Cnt DESC;

如果前缀集中在C:\Program Files\RemiClient这类老路径上，说明文件可能搬过来了但记录没改，用批量替换把前缀改成新的AttachRoot：

-- 先 SELECT 验证影响行数，确认无误后再执行 UPDATE SELECT COUNT(*) FROM dbo.attach_file WHERE file_path LIKE 'C:\Program Files\RemiClient\attach\%'; UPDATE dbo.attach_file SET file_path = REPLACE(file_path, 'C:\Program Files\RemiClient\attach\', 'D:\DataRoot\attach\') WHERE file_path LIKE 'C:\Program Files\RemiClient\attach\%';

先把SELECT COUNT(*)跑一遍确认影响范围，这是血泪经验——直接 UPDATE 之后发现匹配条件写错，附件路径全变成乱码，只能从备份还原。如果文件本身就没搬过来，那就只能从老机器上把附件目录按原结构拷过来，路径能不改就不改，改动越少还原风险越低。

5.4 两台电脑指向同一个库，隔天就有人被锁死

现象是 A 电脑保存单据的时候 B 电脑正在查询，A 卡住十几秒后报超时或"连接被强制关闭"，B 那边偶尔也弹锁等待超时。成因是把单机版的库放在共享盘上给两台机器用，或者两台机器连同一个实例。文件型库放共享盘的问题最严重，SMB 协议下的文件锁语义和本地文件锁不一样，客户端以为自己拿到了独占锁，实际没有，写入冲突时表现就是随机的数据异常。

处置上先明确一条：单机版的设计前提就是单机使用，多终端共享要么换网络版，要么用只读方式。文件型库绝对不要放共享盘，这一点没有折中方案。如果确实需要两台机器看同一份数据，可行的做法是一台作为主机跑客户端并开共享，另一台通过远程桌面的方式使用，数据仍然只有一份、只有一个写入者。实例型库做多机共享相对安全一些，但要确认客户端是不是用了本地临时表、本地缓存文件这类依赖本机状态的设计，有的话在多机上照样出问题，表现是查询结果不一致。

提示：判断是不是并发导致的问题，看 SQL Server 的错误日志里有没有 1205（死锁牺牲者）或 1222（锁请求超时）。有这两个错误码就说明确实是并发冲突，不是网络抖动。

5.5 跨版本升级后一进主界面就弹字段错误

现象是从 4.79 之前的版本升上来，或者把老库挂到新客户端上，登录成功、主界面弹出一串字段名不存在的错误，重装客户端也没用。成因是客户端的代码版本和库结构版本不匹配，新客户端读新字段，老库没有；或者升级脚本只跑了一半，中间某个版本的补丁脚本漏执行了。这类客户端一般在库里有一张版本记录表，记录当前库结构版本号，客户端启动时会比对。

处置顺序是先查库里的版本号，再对照安装包 db 目录里的升级脚本列表，看中间缺了哪几段：

-- 查库结构版本记录，与客户端要求的版本号比对 SELECT * FROM dbo.sys_version ORDER BY ver_id DESC;

# 列出安装包 db 目录里的升级脚本，按文件名排序看中间缺哪段 ls -1 /d/pkg/db/*.sql | sort

如果版本号差了好几级，不要跳着执行最后一段脚本，按顺序逐个跑。跳级执行最常见的后果是中间的字段重命名、类型变更被跳过，最后一段脚本报"列已存在"或"列不存在"，两种情况都会让库停在一个既不是旧版也不是新版的中间态。执行前必须做一次完整备份，并且把脚本执行日志重定向到文件里，出问题能定位到具体哪一句。

6. 把后悔药提前吃下去：升级前的库结构指纹与回滚锚点

升级这件事，最怕的不是升失败，是升失败之后说不清原来是什么样。我在一台跑了两年多的单机版上吃过一次亏：升级脚本执行到一半报错，回滚的时候发现备份是三天前的，中间三天的单据只能手工补录，补了整整一个下午。从那以后我每次动库之前都强制走一遍结构指纹记录，哪怕只是改一个字段长度。

做法很朴素：升级前把库的关键结构指标落成一个基线文件，升级后重新采一次，两份文件做 diff。指标不用多，表数量、字段总数、索引数、几个核心表的行数，足够判断结构有没有被意外改动。

-- 采集库结构指纹：表/字段/索引数量 + 核心表行数 SELECT 'table_count' AS Metric, COUNT(*) AS Val FROM sys.tables UNION ALL SELECT 'column_count', COUNT(*) FROM sys.columns UNION ALL SELECT 'index_count', COUNT(*) FROM sys.indexes WHERE type > 0 UNION ALL SELECT 'fk_count', COUNT(*) FROM sys.foreign_keys UNION ALL SELECT 'rows_bill', COUNT(*) FROM dbo.bill_main UNION ALL SELECT 'rows_customer', COUNT(*) FROM dbo.customer;

把这六行结果连同客户端版本号、库版本号一起存进baseline-YYYYMMDD.txt，升级完成后再跑一遍，用Compare-Object对比两份文件。表数量和字段数量发生变化是正常的（升级就是加字段），但如果字段总数减少了、外键数量掉了，说明升级脚本把某些约束删了没建回来，这种情况必须回滚。行数比对是防"升级脚本误删数据"的最后一道闸，核心表的行数在升级前后必须一致。

回滚锚点要准备三样东西：一份升级前的完整备份、一份升级前的配置文件归档、一份升级前的客户端安装包。第三样最容易被忽略——新版客户端装上去之后，旧版安装包在很多渠道已经拿不到了，想回退到旧版客户端配合旧库，手里没包就只能干等。这三样东西放在同一个以日期命名的目录里，升级出问题时整套回退，不要东拼西凑地只回退其中一项，库和客户端版本错配的排查成本远高于整体回退。

还有一个细节：升级脚本执行前把客户端的自动更新关掉。有些客户端启动时会检测版本并静默拉取更新，你正在手工跑升级脚本，它同时在跑自动更新，两套脚本并发改同一个库，结果就是字段状态混乱。这个坑不常见，但踩上一次够记很久。希望帮到你。

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