企业官网建设流程全解析

简介：这套企业工资管理系统源码基于ASP与SQL数据库构建，面向学习Web开发与企业级应用设计的中初级开发者，也可作为高校课程设计或薪资管理模块定制的参考案例。系统围绕员工信息维护、工资结构设置、薪酬自动计算、个税处理、工资发放记录、报表统计与分级权限管理等环节展开，较完整地呈现了从数据库表设计到页面业务逻辑的实现链路。压缩包共97个文件、约689KB，以67个ASP动态页面为主体，配合6个CSS样式表、GIF与JPG等界面素材及XML配置，并附带MDF与LDF数据库文件，可较方便地还原运行环境。已有423人学习，读者可据此理解ASP连接SQL、执行查询与参数校验的方式，并重点关注登录校验、防止SQL注入、敏感薪资数据权限隔离等实践，适合边调试边梳理模块调用关系。

1. 老架构的工资系统：ASP+SQL 能扛住哪些活

上周一位做企业信息化的朋友发来一份源码包，说公司还在用 Excel 算工资，部门一多就开始对不上账，想找个能自己改的系统先顶上。我打开一看，是套经典的企业工资管理系统源码，ASP + SQL Server，页面是 VBScript 直出 HTML，数据库里几个表把员工、工资项目、月度明细串起来。这种 ASP WEB 架构现在看确实老派，但它有个好处：没有构建、没有依赖包、没有中间件，装好 IIS 和数据库，改一行连接串就能登录。

它干的活也不花哨——员工档案维护、工资项目配置、按月生成工资、批量导入绩效补贴、个人工资条查询、部门汇总。适合两类人：中小企业想用低成本替换掉手里那张容易算错的工资表；以及要接手维护历史系统的开发者，得在原有代码上继续加审批、加导出。后面的内容按「怎么跑起来 → 代码怎么组织 → 薪资怎么算 → 哪里会翻车 → 怎么改」推下去，跟着做能复现，也能看到这套老架构里值得保留的设计。

2. 环境搭建与部署：把 IIS 和 SQL Server 配到位

这套系统能不能跑起来，八成问题出在环境上，而不是代码里。ASP 不是 PHP 那种装个运行时就完事的语言，它寄生在 IIS 的 asp.dll 里，数据库连接又依赖 Windows 上的 OLE DB 提供程序，两个环节任一没配对，页面就给你一片空白或者 500 错误。我一般按「先让静态页出来 → 再让 aspx/asp 解释器生效 → 最后打通数据库」的顺序推进，每步单独验证，出问题能立刻定位是哪一层。

2.1 IIS 站点与应用程序池：老 ASP 的第一道关

在 Windows 功能里勾选 Internet Information Services，重点是「万维网服务 → 应用程序开发功能 → ASP」这一项，很多人只勾了静态内容，结果访问 .asp 文件直接被浏览器下载下来，看到的是源码。装完之后在 IIS 管理器里新建站点，物理路径指向源码根目录，端口别和已有站点冲突。

应用程序池有两个设置必须改。第一是「启用 32 位应用程序」设为 True，原因是老系统常引用 Microsoft.Jet.OLEDB.4.0 这类只有 32 位版本的组件，如果你后续要做 Excel 导入导出，64 位池会直接报「未找到提供程序」。第二是「托管管道模式」用「经典」，ASP 页面不需要 .NET 管道，集成模式偶尔会因为处理程序顺序导致 .asp 映射失效。

# 以管理员身份执行，快速确认 IIS 的 ASP 功能是否已装 dism /online /Get-FeatureInfo /FeatureName:IIS-ASP # 状态显示 Enabled 才算装好；显示 Disabled 就用下面这行装上 dism /online /Enable-Feature /FeatureName:IIS-ASP /All

上面这两条命令只是用来验证和补救，真正建站点还是在图形界面里操作更直观。站点建好后，进「ASP」配置项，把「调试属性 → 将错误发送到浏览器」设为 True，这样页面报错时会直接把行号和错误描述打出来，比看 IIS 日志快得多；「行为 → 启用父路径」设为 True，因为老代码里 include 常写成<!--#include file="../inc/conn.asp"-->这种相对上层目录的形式，不开启就会报包含文件找不到。上线前记得把「将错误发送到浏览器」关掉，否则数据库连接串之类的敏感信息会暴露在页面上。

还有一处容易漏：默认文档。系统入口一般是 index.asp，要在站点的「默认文档」列表里把它加到最前面，否则访问根路径会返回 403 目录列表禁止。

2.2 数据库还原与 conn.asp 连接串

SQL Server 这边，源码包的 sql 目录下通常有一个建库脚本或者一个 .bak 备份。用 SSMS 还原备份最省事，如果只有 .mdf/.ldf，就用「附加」的方式挂上去，注意给运行 IIS 的账户（一般是 NETWORK SERVICE 或自定义的应用程序池标识）授予数据库的读写权限，或者干脆用 SQL 身份验证的账号连，绕开 Windows 账户映射的麻烦。

连接信息集中在 conn.asp 里，这段代码通常被所有页面 include，是全站唯一的数据库入口：

<% ' conn.asp —— 全站数据库连接，所有页面第一行 include 本文件 Dim Conn, ConnStr, DBServer, DBName, DBUser, DBPass DBServer = "127.0.0.1" ' 命名实例写成 127.0.0.1\SQLEXPRESS DBName = "SalaryDB" DBUser = "sa" DBPass = "ChangeMe@2025" ' Network Library=DBMSSOCN 强制走 TCP/IP，避免命名管道解析失败 ConnStr = "Provider=SQLOLEDB.1;Persist Security Info=False;" & _ "User ID=" & DBUser & ";Password=" & DBPass & ";" & _ "Initial Catalog=" & DBName & ";Data Source=" & DBServer & ";" & _ "Network Library=DBMSSOCN" Set Conn = Server.CreateObject("ADODB.Connection") On Error Resume Next Conn.Open ConnStr If Err.Number <> 0 Then Response.Write "数据库连接失败：" & Err.Description Response.End End If On Error GoTo 0 %>

参数逐个说清楚：Provider=SQLOLEDB.1是 SQL Server 的原生 OLE DB 驱动，Windows 自带，不需要额外装；Persist Security Info=False表示连接打开后不再把密码留在 ConnectionString 属性里，属于基本的安全习惯；Network Library=DBMSSOCN是最容易踩坑的一项，不写它的时候驱动可能先尝试命名管道，在跨网段或者防火墙只放行 1433 的环境里就会卡住十几秒然后超时。Initial Catalog是库名，Data Source是实例地址，这两项配错报的是「无法打开登录所请求的数据库」。

如果用的是 SQL Server 2019 以后的版本，SQLOLEDB 仍然可用但已不再更新，可以换成Provider=MSOLEDBSQL，需要先安装对应的驱动。改驱动时注意连接串里要加Encrypt=Optional，新版驱动默认要求加密，老环境没配证书会直接连不上。

2.3 首次登录与基础数据初始化

数据库通了的标志是登录页能正常渲染，而不是一片空白。老系统默认管理员账号一般是 admin，密码在说明文件里，或者库里存的是 MD5 值，得先查一下 sys_user 表。登进去之后别急着录数据，按顺序做三件事。

第一件，改管理员密码，顺便看一眼密码字段是不是明文。如果是明文，说明这套代码的安全基线很低，后面做二次开发时要顺手换成加盐散列，别指望原作者。第二件，进「工资项目」维护，把公司实际用的收入项和扣款项配齐——基本工资、岗位津贴、绩效奖金、加班费、社保个人部分、公积金个人部分、个税、其他扣款，项目顺序决定工资条的显示顺序。第三件，导入或手工录入员工档案，重点是工号唯一、部门归属、银行卡号、基本工资四项，工号重复会导致后续月度工资生成时数据串行。

初始化时把演示数据清掉，但不要用DELETE FROM Employee这种一刀切，先确认外键关系。常见做法是先备份一份空库作为模板，以后每开一个新环境直接还原模板，比每次清理演示数据可靠。

3. 目录结构与请求链路：一个工资查询请求走完全程

ASP 项目没有框架帮你做路由和分层，目录结构就是它的架构图。看一套陌生的 ASP 系统，我先看根目录有哪几个文件夹、include 文件放在哪、后台页面怎么区分权限，基本就能判断这代码是规规矩矩写的还是多年堆出来的。这套工资系统的组织方式比较典型，分公共包含、后台管理、员工自助三层，加一个 sql 目录放建库脚本。

3.1 目录分层与文件职责

/SalarySystem ├─ index.asp 登录入口 ├─ main.asp 登录后的框架页/工作台 ├─ conn.asp 数据库连接 ├─ inc/ │ ├─ config.asp 站点名称、分页大小、上传路径等常量 │ ├─ chkuser.asp 登录态与角色校验 │ ├─ fun.asp 公共函数：日期格式化、金额格式化、字符串截断 │ └─ md5.asp 密码散列 ├─ admin/ │ ├─ emp_list.asp 员工档案列表与增删改 │ ├─ salary_item.asp 工资项目配置 │ ├─ salary_month.asp 月度工资生成与调整 │ ├─ salary_import.asp 绩效/补贴批量导入 │ ├─ report_dept.asp 部门汇总报表 │ └─ sys_user.asp 系统用户与权限 ├─ emp/ │ ├─ my_salary.asp 个人工资条查询 │ └─ pwd_edit.asp 修改密码 ├─ upload/ 导入文件的临时落盘目录 ├─ images/ css/ js/ 静态资源 └─ sql/ └─ salary_db.sql 建库建表脚本 + 初始数据

这个结构里有个隐含约定：admin 目录下的每个页面第一行都 include 权限校验，emp 目录下的页面只认当前登录人。约定靠人守，不靠框架强制，所以接手后第一件事是抽查几个页面看有没有漏掉 include——漏一个就是一个未授权访问入口，这种漏洞在老 ASP 系统里非常普遍。

3.2 通用包含文件：conn.asp 与 chkuser.asp

权限校验文件是整套系统里复用度最高的代码，理解它就理解了登录模型：

<% ' inc/chkuser.asp —— 后台页面统一权限校验，放在每个 admin 页面最顶部 Dim LoginUserID, LoginUserName, LoginUserRole LoginUserID = Session("UserID") LoginUserName = Session("UserName") LoginUserRole = Session("UserRole") ' 1=超管 2=人事 3=财务 4=普通员工 ' 未登录：清 Session 并跳回登录页，用 top 是为了跳出框架页 If IsEmpty(LoginUserID) Or Trim(LoginUserID & "") = "" Then Session.Abandon Response.Write "<script>alert('登录已过期，请重新登录');top.location.href='/index.asp';</script>" Response.End End If ' 角色越权：只有 1、2 能进 admin 目录 If CInt(LoginUserRole) > 2 Then Response.Write "<script>alert('没有访问权限');history.back();</script>" Response.End End If %>

逻辑很直白：Session 里存三个值，用户 ID、姓名、角色编号，任何一项缺失就判定未登录。Response.End是关键，它会立刻终止脚本执行，防止后续的数据库查询代码继续跑；如果只写 Response.Redirect 而不 End，页面剩下的代码照样执行，等于校验形同虚设，这是审代码时要重点看的点。top.location.href而不是location.href，是因为后台常用框架页布局，在子框架里跳转会导致登录页嵌在框架里显示。

角色编号用数字而不是角色名字符串，好处是比较方便、存储省空间，代价是可读性差，接手时要在 config.asp 里找到映射注释。我一般会在二次开发时把它改成常量定义，比如Const ROLE_ADMIN = 1，避免代码里到处是魔法数字。

3.3 一次工资查询的执行链路

拿「员工查自己上月工资」这个动作，把链路走一遍：浏览器请求/emp/my_salary.asp?ym=202506，IIS 根据处理程序映射把 .asp 交给 asp.dll，asp.dll 从上到下逐行解释 VBScript，遇到 include 先把公共文件的内容拼进来，然后依次执行——校验登录、打开数据库连接、拼 SQL、拿记录集、循环输出 HTML 表格、关闭对象。整个过程是同步阻塞的，页面输出完才结束，没有异步、没有模板引擎。

<% ' emp/my_salary.asp —— 个人工资条查询（按月份） Dim ym, rs, totalIncome, totalDeduct ym = Trim(Request.QueryString("ym")) If ym = "" Then ym = Year(Date()) & Right("0" & Month(Date()), 2) ' 参数只允许 6 位数字，先过滤再拼 SQL，挡住最基础的注入 If Len(ym) <> 6 Or Not IsNumeric(ym) Then Response.Write "<script>alert('月份参数不合法');history.back();</script>" Response.End End If Set rs = Server.CreateObject("ADODB.Recordset") rs.Open "SELECT i.ItemName, i.ItemType, s.Amount " & _ "FROM SalaryMonth s INNER JOIN SalaryItem i ON s.ItemID = i.ItemID " & _ "WHERE s.EmpID = " & CLng(Session("EmpID")) & " AND s.SalaryYM = '" & ym & "' " & _ "ORDER BY i.ItemOrder", Conn, 1, 1 totalIncome = 0 : totalDeduct = 0 Do While Not rs.EOF If rs("ItemType") = 1 Then totalIncome = totalIncome + CDbl(rs("Amount")) Else totalDeduct = totalDeduct + CDbl(rs("Amount")) End If rs.MoveNext Loop %>

这段代码有三处值得说。CLng(Session("EmpID"))强制转型，防止 Session 被篡改成字符串后拼出畸形 SQL；ym做了长度和数字双重校验，虽然不如参数化查询彻底，但能挡掉绝大多数扫描器；记录集用1, 1打开，即 adOpenKeyset + adLockReadOnly，只读场景下锁开销最小。真正的实发金额是收入合计减扣款合计，代码里分开累加再相减，而不是直接对 Amount 求和，是因为扣款在库里存的是正数，靠 ItemType 区分方向，混在一起加会算错。

页面末尾必须有rs.Close : Set rs = Nothing。ASP 没有自动回收，连接和记录集不显式关闭，并发一上来连接池就被占满，表现是系统用着用着突然全体卡死，重启 IIS 又好了——这是老 ASP 项目最经典的黑匣子故障之一。

4. 核心模块拆解：工资项目、算薪逻辑与批量导入

工资系统的复杂点从来不在页面，而在数据模型和计算口径。同样是「应发工资」，有的公司把它当明细行的求和结果，有的公司把它当独立字段存下来，两种设计在后续调整时成本完全不同。这套系统用的是明细行模型：一个员工一个月对应多条工资项目记录，应发、实发都是聚合出来的。好处是灵活，加一个补贴项不用改表结构；代价是每次查询都要 JOIN 和 SUM，数据量大了要建索引。

4.1 三张核心表的设计

-- 员工档案 CREATE TABLE Employee ( EmpID INT IDENTITY(1,1) PRIMARY KEY, EmpNo VARCHAR(20) NOT NULL UNIQUE, -- 工号，业务唯一键 EmpName NVARCHAR(30) NOT NULL, DeptID INT NULL, BankNo VARCHAR(30) NULL, BaseSalary DECIMAL(12,2) DEFAULT 0, -- 基本工资，算薪起点 Status TINYINT DEFAULT 1 -- 1在职 0离职 ); -- 工资项目字典 CREATE TABLE SalaryItem ( ItemID INT IDENTITY(1,1) PRIMARY KEY, ItemName NVARCHAR(20) NOT NULL, -- 基本工资/绩效/社保/公积金/个税 ItemType TINYINT NOT NULL, -- 1=收入 2=扣款 ItemOrder INT DEFAULT 0, -- 工资条显示顺序 IsTax TINYINT DEFAULT 0 -- 是否参与计税 ); CREATE UNIQUE INDEX UX_ItemName ON SalaryItem(ItemName); -- 月度工资明细 CREATE TABLE SalaryMonth ( ID INT IDENTITY(1,1) PRIMARY KEY, EmpID INT NOT NULL, SalaryYM CHAR(6) NOT NULL, -- 形如 202506 ItemID INT NOT NULL, Amount DECIMAL(12,2) DEFAULT 0, CreateTime DATETIME DEFAULT GETDATE(), CONSTRAINT UQ_Salary UNIQUE (EmpID, SalaryYM, ItemID) ); CREATE INDEX IX_Salary_YM ON SalaryMonth(SalaryYM, EmpID);

字段选型有两个细节。金额统一用DECIMAL(12,2)而不是FLOAT，浮点在累加几十行之后会出现 0.01 级别的偏差，工资单上差一分钱都要被财务追问半天，这是血泪经验。SalaryYM用 CHAR(6) 存年月而不是 DATE，是因为按月查询、按月分组是最高频操作，字符串等值比较比日期函数快，而且不受时区影响。唯一约束UQ_Salary保证一个员工一个月一个项目只有一条记录，重复生成时数据库层面直接报错，比应用层判断可靠。

IsTax这个字段决定了计税范围。有些补贴不计税，有些补贴要并入综合所得，靠这个标记在算薪时筛选，比在代码里硬编码项目名称强得多——公司换个补贴名，代码不用动。

4.2 月度工资生成与计算口径

算薪的顺序不能乱：先算应发合计，再算社保公积金，再算应纳税所得额，最后算个税和实发。顺序颠倒会导致个税基数算错，而这种错误往往要到月底对账才发现。

<% ' inc/tax.asp —— 按月超累进速算，演示用口径 Function CalcTax(TaxableIncome) Dim Rate, Deduct If TaxableIncome <= 0 Then CalcTax = 0 Exit Function End If Select Case True Case TaxableIncome <= 3000: Rate = 0.03: Deduct = 0 Case TaxableIncome <= 12000: Rate = 0.10: Deduct = 210 Case TaxableIncome <= 25000: Rate = 0.20: Deduct = 1410 Case TaxableIncome <= 35000: Rate = 0.25: Deduct = 2660 Case TaxableIncome <= 55000: Rate = 0.30: Deduct = 4410 Case Else: Rate = 0.35: Deduct = 7160 End Select CalcTax = RoundHalfUp(TaxableIncome * Rate - Deduct, 2) End Function ' 银行家舍入会坑人，自己写四舍五入 Function RoundHalfUp(num, digits) Dim factor factor = 10 ^ digits RoundHalfUp = Int(num * factor + 0.5) / factor End Function %>

Select Case True这种写法在 VBScript 里是合法的，等价于一串 if-else，读起来比嵌套 if 清爽。Deduct是速算扣除数，把分级计算压缩成一次乘减，这是税务计算的常规做法。重点在RoundHalfUp：VBScript 内置的 Round 用的是银行家舍入，0.125 会舍成 0.12 而不是 0.13，单条看不出来，几百人乘以十几个项目，累计误差能到几块钱，财务一眼就能看出总数对不上。

生成逻辑本身是一个双层循环：外层遍历在职员工，内层按项目写入明细。

<% ' admin/salary_month_do.asp —— 按月批量生成工资 Dim ym, rsEmp, empId, base, gross, social, fund, tax, netAmt ym = Trim(Request.Form("ym")) ' 幂等保护：已生成过就直接退回，避免重复造数 Dim rsChk Set rsChk = Conn.Execute("SELECT COUNT(1) AS C FROM SalaryMonth WHERE SalaryYM='" & ym & "'") If rsChk("C") > 0 Then Response.Write "<script>alert('该月份已生成，请先撤销再重新生成');history.back();</script>" Response.End End If Set rsChk = Nothing Set rsEmp = Conn.Execute("SELECT EmpID, BaseSalary FROM Employee WHERE Status=1") Do While Not rsEmp.EOF empId = rsEmp("EmpID") base = CDbl(rsEmp("BaseSalary")) gross = base ' 实际项目里这里叠加绩效、补贴等收入项 social = RoundHalfUp(gross * 0.105, 2) ' 养老8%+医疗2%+失业0.5%，示例比例 fund = RoundHalfUp(gross * 0.07, 2) ' 公积金 7% tax = CalcTax(gross - social - fund - 5000) netAmt = gross - social - fund - tax WriteItem empId, ym, "基本工资", 1, gross WriteItem empId, ym, "社保个人", 2, social WriteItem empId, ym, "公积金个人", 2, fund WriteItem empId, ym, "个人所得税", 2, tax WriteItem empId, ym, "实发工资", 1, netAmt rsEmp.MoveNext Loop rsEmp.Close : Set rsEmp = Nothing %>

WriteItem是个封装好的子过程，内部按项目名查 ItemID 再插入，不存在就报错，这样项目字典改了名字也不会静默失败。百分比写死在代码里是这套系统的短板，正规做法是从一张社保参数表里读，按城市和年度区分，改造时这是第一优先级的重构点。

另外要注意「实发工资」也被存成了一行明细。这属于冗余存储，好处是查询时不用每次聚合，坏处是明细和汇总可能不一致——某天有人手工改了一条社保金额，实发那行却没跟着变，账就平不了。我的做法是实发不落库，查询时用 SUM 现算，宁可慢一点也不要两套真相。

4.3 批量导入：为什么不用 Excel 直读

绩效和补贴金额通常来自业务部门发的 Excel。老代码里常见写法是用 JET 驱动直接SELECT * FROM [Sheet1$]，图省事，但这条路坑很深：服务器上没装 Office 或 Access 数据库引擎就报「未找到可安装的 ISAM」，装了又分 32 位 64 位，客户换台机器就得重新折腾一轮。我现在一律让业务方另存为 CSV，用文件系统对象逐行解析，依赖最少。

<% ' admin/salary_import_do.asp —— 逐行解析 CSV 并更新明细 Dim fso, ts, line, arr, okCount, errCount, empNo, itemName, amount okCount = 0 : errCount = 0 Set fso = Server.CreateObject("Scripting.FileSystemObject") Set ts = fso.OpenTextFile(Server.MapPath("../upload/salary.csv"), 1, False, -2) If Not ts.AtEndOfStream Then ts.ReadLine ' 跳过表头：工号,项目,金额 Do While Not ts.AtEndOfStream line = ts.ReadLine arr = Split(line, ",") If UBound(arr) >= 2 Then empNo = Trim(arr(0)) itemName = Trim(arr(1)) amount = Trim(arr(2)) If IsNumeric(amount) And empNo <> "" Then ' 用子查询按工号定位员工，按项目名定位项目，避免依赖自增 ID Conn.Execute "UPDATE SalaryMonth SET Amount=" & CDbl(amount) & _ " WHERE SalaryYM='" & ym & "' AND EmpID=(SELECT EmpID FROM Employee WHERE EmpNo='" & empNo & "')" & _ " AND ItemID=(SELECT ItemID FROM SalaryItem WHERE ItemName=N'" & itemName & "')" okCount = okCount + 1 Else errCount = errCount + 1 End If End If Loop ts.Close : Set ts = Nothing : Set fso = Nothing %>

OpenTextFile的第四个参数-2表示用系统默认编码读取，中文 Windows 上就是 GBK，如果 CSV 是 UTF-8 存的，读出来全是乱码，这时候改成-1（Unicode）或者先转码。Split(line, ",")是最朴素的解析，遇到金额里带千分位逗号（如 1,200.00）就会错位，正规做法是让业务方导出时不带千分位，或者在解析时做引号识别。

最该警惕的是这段代码里的字符串拼接。工号和项目名来自外部文件，直接拼进 SQL 就是注入入口，虽然内网环境风险低，但一套能被人从上传文件打进数据库的系统，出事只是时间问题。改造方向很明确：换成ADODB.Command加参数，或者至少对字符串做单引号转义。

4.4 查询统计与分页

个人工资条和部门汇总都涉及分页。ASP 没有现成的分页组件，靠 ADO 记录集的PageSize和AbsolutePage属性，本质是把整个结果集拉到内存里再切片，数据量小的时候无所谓，几万条明细就会明显变慢。真要优化，得改成分页 SQL（ROW_NUMBER 或 OFFSET FETCH），这属于二次开发范畴。

<% ' emp/my_salary.asp 片段 —— 按月分组 + 记录集分页 Dim page, pageSize, rs page = CLng("0" & Request.QueryString("page")) If page < 1 Then page = 1 pageSize = 12 Set rs = Server.CreateObject("ADODB.Recordset") rs.Open "SELECT SalaryYM, " & _ "SUM(CASE WHEN ItemType=1 THEN Amount ELSE 0 END) AS TotalIn, " & _ "SUM(CASE WHEN ItemType=2 THEN Amount ELSE 0 END) AS TotalOut " & _ "FROM SalaryMonth s INNER JOIN SalaryItem i ON s.ItemID=i.ItemID " & _ "WHERE s.EmpID=" & CLng(Session("EmpID")) & " " & _ "GROUP BY SalaryYM ORDER BY SalaryYM DESC", Conn, 1, 1 rs.PageSize = pageSize If Not (rs.EOF Or rs.BOF) Then If page > rs.PageCount Then page = rs.PageCount rs.AbsolutePage = page End If %>

CLng("0" & 参数)是个小技巧：参数为空时拼成 "0"，转成数字是 0，后面兜底成第 1 页，省掉一层判断。CASE WHEN在一条 SQL 里同时算应发和扣款，比查两次再对齐快。GROUP BY SalaryYM让结果按月聚合，一年正好 12 条，分页其实可以取消，但保留着方便以后按月展开明细。

报表那侧同理，部门汇总是把 EmpID 换成 DeptID 再做 SUM，难点不在 SQL，而在离职员工是否计入、部门调整后历史数据归哪个部门。常见做法是月度工资表里冗余存一份当时的部门 ID，避免员工调岗后历史报表全部变样。

5. 常见问题与排查：跑不起来、乱码、算错钱的 5 个坑

老 ASP 项目的问题有个特点：现象看起来五花八门，根因往往就那几类——环境配置、编码、数值精度、会话状态。下面这五条是我在不同机器上反复遇到的，按「现象 → 原因 → 解决」记下来，下次再碰到可以直接对号入座。

5.1 部署与环境类问题

现象一：浏览器访问 .asp 页面，直接弹出下载框，或者页面上显示源代码。原因有两个层次。表层是 IIS 没有安装 ASP 应用程序开发功能，静态文件处理器接管了请求，把 .asp 当成普通文件返回；深层是处理程序映射里 .asp 的映射被删了或者指向了错误的 DLL。解决：先在 Windows 功能里确认 IIS-ASP 已启用，再进 IIS 管理器的「处理程序映射」找ASPClassic，路径应该是%windir%\System32\inetsrv\asp.dll，受限动作为「脚本」。如果映射存在但还是下载，检查站点的 MIME 类型里是不是有人手工加了.asp → application/octet-stream，删掉即可。

现象二：数据库连不上，报「未找到提供程序，可能未正确安装」或800a0e7a。原因几乎都是应用程序池的位数问题。Microsoft.Jet.OLEDB.4.0只有 32 位版本，而 Windows Server 默认创建的是 64 位池，进程一加载就找不到驱动。解决：应用程序池 → 高级设置 → 启用 32 位应用程序 → True，然后回收池。如果代码里用的是SQLOLEDB，这个驱动在 64 位下正常，那就往另一个方向查——SQL Server 的 TCP/IP 协议是否启用、1433 端口是否放行、SQL Browser 服务是否在跑（命名实例必须靠它解析端口）。

现象三：页面中文全是问号，或者数据库里存进去的备注变成乱码。原因是编码链路不一致。ASP 页面的编码由<%@LANGUAGE="VBSCRIPT" CODEPAGE="936"%>决定，Response 的输出编码由Response.Charset决定，数据库字段又分 varchar 和 nvarchar 两套。三层里任意两层对不上就出乱码。解决：先统一到 GBK 这条链路——页面声明 CODEPAGE=936，在 conn.asp 里加Session.CodePage = 936，数据库字段能用 nvarchar 就用 nvarchar。如果要迁到 UTF-8，三处必须一起改：页面存成 UTF-8 无 BOM、CODEPAGE="65001"、连接串里加charset=utf-8的对应设置，改一半比不改更乱。

5.2 数据与业务类问题

现象四：生成完工资，实发金额和财务用计算器按出来的差几分钱。原因通常有两个。一是金额字段建成了FLOAT或REAL，浮点累加天然有误差；二是用了 VBScript 内置的Round，它是银行家舍入，遇到 .5 结尾时向偶数靠拢，和财务习惯的四舍五入不一致。解决：字段类型统一改DECIMAL(12,2)，代码里换成自己写的RoundHalfUp，并且规定每个项目算完立即舍入一次，而不是最后总算完再舍——两次舍入的差异在个税上会被放大。改完之后拿三个典型薪资档位（低于起征点、中间档、高档）手工验算一遍，别只信系统输出的总数。

现象五：登录一会儿就掉线，尤其是一段时间没操作之后，点任何菜单都跳回登录页。原因有三个可能：IIS 应用程序池的空闲超时默认 20 分钟，池一回收，进程内 Session 全部丢失；ASP 会话超时默认也是 20 分钟；如果部署了两台机器做负载均衡而没做会话共享，请求打到另一台就等于没登录。解决：单机部署的话，把应用程序池的「空闲超时」设为 0（不回收）、「定期回收时间」调大到 1740 分钟以上，同时在 IIS 的 ASP 配置里把「会话属性 → 超时」改成 60 分钟。多机部署就得动架构了，把登录态从 Session 挪到数据库或加密 Cookie 里，这是改造量最大的一条。

这五条里，前三条属于一次性配置，配好之后不会再犯；后两条是代码层面的问题，会在业务量增长后逐渐暴露。我的习惯是新环境部署完先拿一个测试员工走一遍完整流程：登录、生成工资、导入一条绩效、查个人工资条、看部门汇总，五步都过再交给使用方，能提前挡掉大部分问题。

6. 二次开发：加审批状态与薪资条导出

这套系统最缺的是流程控制。现在生成完工资就能直接改，改完没有任何痕迹，月底出了问题根本查不到是谁动的。我的改造思路是给月度工资加状态机，而不是加一个复杂的审批引擎——老系统扛不住重架构，能用一个字段解决的问题不要引工作流。

具体做法是给 SalaryMonth 加AuditStatus字段：0 草稿、1 待审、2 已审、3 已发放；再加一张SalaryLog记录每次状态变更的操作人、时间、IP 和变更前后的金额快照。

拦截点放在所有写操作之前，一个公共函数搞定：

<% ' inc/chk_editable.asp —— 状态机拦截，所有改工资的页面先调用 Function CanEditSalary(ym) Dim rsSt Set rsSt = Conn.Execute("SELECT TOP 1 AuditStatus FROM SalaryMonth WHERE SalaryYM='" & ym & "'") If rsSt.EOF Then CanEditSalary = True ' 还没生成，允许生成 Else CanEditSalary = (rsSt("AuditStatus") = 0) End If rsSt.Close : Set rsSt = Nothing End Function Sub AssertEditable(ym) If Not CanEditSalary(ym) Then Response.Write "<script>alert('该月工资已提交，不能再修改');history.back();</script>" Response.End End If End Sub %>

AssertEditable在每个 UPDATE 之前调用一次，成本是一次轻量查询，换来的是数据不可篡改。日志表用触发器写还是应用层写，我倾向前者——应用层总会有人漏调，触发器不会。触发器里用INSERTED和DELETED对比，把变更前后的金额都记下来，出问题能还原。

另一个高频需求是薪资条导出。业务方要的是每人一份、能直接发下去的 PDF 或 Excel，不是一张大表。成本最低的改法是保留现有的查询页面，加一套打印样式表，用浏览器自带的「打印为 PDF」；如果必须程序化生成，就用命令行工具在服务器上把页面渲染成 PDF，ASP 里用WScript.Shell调用，注意给输出目录写权限。

导出的坑主要在文件名和并发。文件名带中文要做 URL 编码，否则下载下来是乱码；多人同时导出时临时文件会重名，用「工号+年月+时间戳」做文件名能避开。另外导出属于重操作，别在页面里同步跑完再返回，人多的时候会超时，常见做法是写一个任务表，后台慢慢生成，前端轮询进度。

这套源码我前后改过三个版本，第一次图快，直接在原表上加字段，结果历史数据的默认值全是 NULL，算汇总时 SUM 出来一堆空；从那以后我每次动表结构，都强制先写一个带DEFAULT的ALTER TABLE，再补一条回填脚本，最后拿改前的备份跑一遍对比。老系统没有后悔药，只能自己多留一手。希望帮到你。

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