企业官网建设流程全解析

简介：这是一份面向ASP开发学习者与中小企业信息化建设者的企业工资管理系统完整源码，采用ASP+SQL技术栈实现员工档案管理、工资项设置、自动计薪、个税处理、报表统计及权限控制等核心模块，可直接部署或二次开发。压缩包共97个文件，以67个asp页面为主体，配合6个css样式、11个gif与5张jpg图片构建界面，并含1个db数据库文件（另有mdf/ldf数据与日志），整体仅689KB，结构紧凑、便于快速分析。目前已有421人学习下载，适合用来掌握ASP服务端脚本与SQL Server数据库的交互方式、动态查询语句编写以及防SQL注入等安全实践。源码还包含考勤、加班、奖扣款等子模块，目录层次清晰，可作为企业级Web管理系统的教学范例和开发模板。

1. 企业工资管理系统源码ASP+SQL：老技术栈为什么还在项目里活着

很多开发者拿到“企业工资管理系统源码ASP+SQL”这个标题，第一反应是“这套技术栈早过时了”。但真正接手过老系统的人都知道，这类源码至今还在大量中小企业里稳定跑着：一堆 .asp 页面加一个 SQL Server 数据库备份，支撑着每月一次的全员工资核算。这篇笔记不讲“该不该换架构”的空话，而是沿着这类源码最常见的模块——登录、员工档案、工资计算、查询导出——把运行环境、数据库设计、核心代码和部署踩坑一次讲透。适合三类人：接手维护老 ASP 系统的开发者、想用低成本方案部署工资系统的小企业技术负责人，以及拿这个题目做课程设计的学生。只要你的 Windows 机器能装 IIS，这套流程就能完整复现。

2. 运行环境与数据库设计：ASP+SQL 工资系统的地基

2.1 运行环境选型：IIS 版本与 SQL Server 版本的对应关系

ASP 是 Windows 平台上 IIS 内置的脚本引擎，不需要单独安装运行时。老源码的原始运行环境五花八门，接手时先确认环境再动手，能省掉大量排查时间。常见的组合有这么几类：

SQL Server 版本方面，老源码的数据库备份文件（.bak）经常来自 SQL Server 2000 或 2005，这些备份在 SQL Server 2012 以后的版本里不能直接还原。常见做法是先在一台装有 SQL Server 2008 R2 的机器上还原，再把数据库分离，用 .mdf/.ldf 文件附加到新版本实例上。我一般会先问一句“备份文件是哪年哪个版本导出的”，版本相差太远就直接走这条中转路径，别硬试。

IIS 里要让 ASP 跑起来，需要确保“应用程序开发功能”里的 ASP 勾选启用，这个功能默认是关闭的。另外还要留意应用程序池的“启用 32 位应用程序”选项，它和数据库驱动位数相关，具体在避坑章节里专门展开。

2.2 数据库设计：四张核心表与工资数据的拆分方式

工资系统的数据库结构大同小异，标题里的 SQL 指的就是 SQL Server。最常见的核心表就四张：部门表、员工表、工资表、用户表。部门表与员工表是一对多关系，员工表与工资表是一对多关系，用户表独立用于登录权限。这样的拆分方式是为了让“员工资料”和“每月工资”解耦：员工涨薪只改 Employee 表，历史工资记录不受影响。

-- 部门表 CREATE TABLE [dbo].[Department]( DeptID INT IDENTITY(1,1) PRIMARY KEY, DeptName NVARCHAR(50) NOT NULL, Remark NVARCHAR(200) NULL ); -- 员工表 CREATE TABLE [dbo].[Employee]( EmpID INT IDENTITY(1,1) PRIMARY KEY, EmpNo NVARCHAR(20) NOT NULL UNIQUE, -- 工号，工资计算和查询都靠它 EmpName NVARCHAR(50) NOT NULL, -- 姓名用 NVARCHAR，兼容中文不乱码 DeptID INT NOT NULL REFERENCES Department(DeptID), BaseSalary DECIMAL(10,2) NOT NULL DEFAULT 0, -- 基本工资，金额一律 decimal HireDate DATETIME NULL, -- 入职日期 Status INT NOT NULL DEFAULT 1 -- 1在职 0离职，离职员工不再参与核算 ); -- 工资表：按月保存，一人一月一条 CREATE TABLE [dbo].[Salary]( SalaryID INT IDENTITY(1,1) PRIMARY KEY, EmpID INT NOT NULL REFERENCES Employee(EmpID), SalaryMonth CHAR(6) NOT NULL, -- 格式 202506，比 DATETIME 更稳 AttendanceDeduct DECIMAL(10,2) NOT NULL DEFAULT 0, -- 考勤扣款 Bonus DECIMAL(10,2) NOT NULL DEFAULT 0, -- 奖金/加班费 OtherDeduct DECIMAL(10,2) NOT NULL DEFAULT 0, -- 其他扣款 SocialSecurity DECIMAL(10,2) NOT NULL DEFAULT 0, -- 社保个人部分 NetSalary DECIMAL(10,2) NOT NULL DEFAULT 0, -- 实发工资 CONSTRAINT UQ_SalaryMonth UNIQUE(EmpID, SalaryMonth) ); -- 管理员用户表 CREATE TABLE [dbo].[SysUser]( UserID INT IDENTITY(1,1) PRIMARY KEY, UserName NVARCHAR(50) NOT NULL UNIQUE, PassWord NVARCHAR(32) NOT NULL, -- MD5 密文，别存明文 UserRole INT NOT NULL DEFAULT 0 -- 0普通管理员 1超级管理员 );

这段建表 SQL 里最有讲究的是 SalaryMonth 用 CHAR(6) 而不是日期类型。工资核算按自然月归档，202506 这种字符串既能直接用大于小于比较，又不会受 SQL Server 的区域日期设置影响翻车，这是老系统里最稳的约定。DECIMAL(10,2) 用于所有金额字段，避免浮点型在累加时出现精度偏差；10 位总长度够绝大多数企业的单月工资量级。EmpNo 加 UNIQUE 约束保证工号不重复，这是工资数据准确性的第一道防线。

2.3 ADO 连接：连接串的写法与每个参数的含义

ASP 操作 SQL Server 的标准方式是 ADO，核心是创建 ADODB.Connection 对象再打开连接。老源码里通常会在根目录放一个 conn.asp，全站用 引入，页面里直接用 conn 变量执行 SQL。连接串有三种写法，按部署环境选：

<% ' 写法一：SQL Server 身份验证，最常用 Dim conn Set conn = Server.CreateObject("ADODB.Connection") conn.Open "Provider=SQLOLEDB;Data Source=127.0.0.1;Initial Catalog=SalaryDB;User ID=sa;Password=sa123" ' 写法二：Windows 集成验证，适合内网域环境 ' conn.Open "Provider=SQLOLEDB;Data Source=SERVER01;Initial Catalog=SalaryDB;Integrated Security=SSPI;" ' 写法三：命名管道加超时控制，老网络环境偶尔需要 ' conn.Open "Provider=SQLOLEDB;Data Source=np:127.0.0.1;Initial Catalog=SalaryDB;User ID=sa;Password=sa123;Connect Timeout=10;" %>

Provider=SQLOLEDB 是兼容性最好的老牌 OLEDB 驱动，覆盖 SQL Server 2000 到 2016 全系列，这也是老源码里出现率最高的写法。Data Source 写服务器 IP 或实例名，本机调试直接用 127.0.0.1，比写机器名更快，也避开了 DNS 解析的坑。Initial Catalog 是数据库名，User ID 和 Password 是 SQL 账号。Connect Timeout 的单位是秒，设太短会在数据库重启时频繁报超时，10 秒是个保守值。

提示：conn.asp 里连接串是明文，上线前务必把数据库账号权限收窄到只读工资库，别用 sa 跑业务。

写完连接还要记得释放。页面结束前执行 conn.Close 和 Set conn = Nothing，否则 IIS 进程里的连接不会立刻回收，并发一高就把连接池占满，这是老系统最常见的性能隐患。另外，老系统的通病是连接串写在每个页面的顶部而不是统一个文件里，导致换服务器时漏改一处、整站报错，接手后第一件事应该是把所有连接统一收进 conn.asp。

3. 核心模块实现：登录校验、员工档案与工资计算逻辑

3.1 登录与 Session 权限：防越权的 ASP 写法

工资系统第一个要写死的模块是登录。老 ASP 没有框架级的鉴权机制，全靠 Session 变量配合 include 文件实现。登录页提交表单后，比对用户表，通过就写 Session，失败就跳回登录页。关键点是密码不能明文比对，老源码里如果是明文，接手后第一件事就是改成 MD5。

<% ' login.asp 处理登录表单 Dim username, password, rs, sql username = Trim(Request.Form("username")) password = Trim(Request.Form("password")) ' 老系统的标准做法是 MD5 后比对，MD5 函数一般在 md5.asp 里实现 sql = "SELECT UserID, UserRole FROM SysUser WHERE UserName='" & username & "' AND PassWord='" & MD5(password) & "'" Set rs = conn.Execute(sql) If Not rs.EOF Then Session("UserID") = rs("UserID") Session("UserRole") = rs("UserRole") Session("UserName") = username Response.Redirect "index.asp" Else Response.Write "<script>alert('用户名或密码错误');history.back();</script>" End If rs.Close : Set rs = Nothing %>

这段代码同时暴露了老 ASP 系统的两个通病：字符串拼接 SQL 和明文参数传递。生产环境不能直接这么上线，最低成本的加固是在拼 SQL 前把单引号替换成两个单引号，即 Replace(username, "'", "''")，能挡住大部分注入脚本。更彻底的做法是改用 ADO Command 的 Parameters 参数化查询，这个改法在后面避坑章节里给出具体代码。

登录之后的权限控制靠一个公共文件，比如 checklogin.asp，每个需要鉴权的页面第一行 include 它。超级管理员功能（批量初始化工资、删除员工）还要检查角色：

<% ' checklogin.asp，每个受保护页面第一行引入 If Session("UserID") = "" Then Response.Redirect "login.asp" End If ' 只有超级管理员允许访问的功能 If Session("UserRole") = 0 Then Response.Write "<script>alert('权限不足');history.back();</script>" Response.End End If %>

这段要注意 Response.End 必须写，否则页面后面的代码会继续执行。很多老系统的越权漏洞就是漏了 Response.End，页面已经输出了警告，但业务逻辑照跑。写权限控制时，我的习惯是把“必须登录”和“必须超管”分成两个判断块，而不是塞在一个 If 里，这样日志里能分辨是被踢回登录页还是权限不足。

3.2 员工档案管理：新增、修改与分页列表的标准套路

员工档案是工资计算的数据源，页面一般是 employee_list.asp 列出在职员工，employee_edit.asp 负责新增和修改。老系统的套路是先判断 Request.Form 里有没有提交数据，有就执行更新，没有就带参数读记录显示表单。新增和修改合并成一个页面，用 empid 参数区分，能减少一半文件量。

<% ' employee_edit.asp 同时处理新增和修改 Dim empid, empno, empname, deptid, basesalary, action empid = Trim(Request("empid")) action = Trim(Request("action")) If action = "save" Then empno = Trim(Request.Form("empno")) empname = Trim(Request.Form("empname")) deptid = Trim(Request.Form("deptid")) basesalary = Trim(Request.Form("basesalary")) ' 工号、姓名不能为空，金额必须是数字 If empno = "" Or empname = "" Or Not IsNumeric(basesalary) Then Response.Write "<script>alert('请检查输入');history.back();</script>" Response.End End If ' 姓名里的单引号转义，简单防注入 empname = Replace(empname, "'", "''") If empid = "" Then ' 新增，入职日期取服务器当前时间 sql = "INSERT INTO Employee(EmpNo, EmpName, DeptID, BaseSalary, HireDate, Status) VALUES('" & empno & "','" & empname & "'," & deptid & "," & basesalary & ",'" & Now() & "',1)" Else ' 修改已有员工 sql = "UPDATE Employee SET EmpNo='" & empno & "', EmpName='" & empname & "', DeptID=" & deptid & ", BaseSalary=" & basesalary & " WHERE EmpID=" & empid End If conn.Execute(sql) Response.Redirect "employee_list.asp" End If %>

IsNumeric 是 VBScript 验证输入的第一道门槛，能挡住字母和空字符串，但它对 "12e3" 这种科学计数法会误判为数字，所以严谨的做法是用正则验证 ^\d+(.\d{1,2})?$。实际项目里我一般直接上正则，老系统里的 IsNumeric 能用，但别神化它。

列表页的核心是分页，老 ASP 的分页套路绕不开 ADODB.Recordset 的 PageSize 和 AbsolutePage 两个属性。工资系统的员工量通常几百人，直接查出来再分页完全够用，不必上存储过程：

<% ' employee_list.asp 分页列表 Dim rs, page, pagesize, totalpage pagesize = 20 page = CLng(Request("page")) If page < 1 Then page = 1 Set rs = Server.CreateObject("ADODB.Recordset") rs.CursorLocation = 3 ' adUseClient 客户端游标，分页必需 rs.Open "SELECT e.EmpID, e.EmpNo, e.EmpName, d.DeptName, e.BaseSalary, e.Status FROM Employee e LEFT JOIN Department d ON e.DeptID=d.DeptID WHERE e.Status=1 ORDER BY e.EmpNo", conn, 1, 3 rs.PageSize = pagesize totalpage = rs.PageCount If page > totalpage Then page = totalpage rs.AbsolutePage = page Do While Not rs.EOF And rs.AbsolutePage = page ' 渲染一行员工记录，这里省略 HTML 输出 Response.Write rs("EmpName") & " | " & rs("DeptName") & "<br>" rs.MoveNext Loop rs.Close : Set rs = Nothing %>

CursorLocation=3 和 LockType=3 是老 ASP 分页的两块基石，缺少任何一个都会在设置 AbsolutePage 时报错。CursorLocation 必须放在 Open 之前设置，这是新手最容易犯的顺序错误。rs.AbsolutePage = page 后，rs 指针已经跳到该页第一条记录，循环条件里再判断 AbsolutePage 是为了防止最后一页超出范围。

3.3 工资计算：应发、扣款、实发的关系与落库逻辑

工资计算是整套系统的核心，老源码的逻辑一般是一个月跑一次：录入考勤扣款、奖金、社保后，用基本工资加奖金减各类扣款得到实发工资。计算逻辑分两层：页面负责收集输入，SQL 负责算结果并落库。关键设计是基本工资从 Employee 表读取，不在工资录入页手填，避免两边数据不一致。

<% ' salary_calc.asp 单员工单月工资计算 Dim salarymonth, empid, attendance, bonus, other, social, net salarymonth = Trim(Request.Form("salarymonth")) ' 格式 202506 empid = Trim(Request.Form("empid")) attendance = CDbl(Request.Form("attendance")) bonus = CDbl(Request.Form("bonus")) other = CDbl(Request.Form("other")) social = CDbl(Request.Form("social")) ' 基本工资从员工档案取，不允许手填 sql = "SELECT BaseSalary FROM Employee WHERE EmpID=" & empid Set rs = conn.Execute(sql) If rs.EOF Then Response.Write "<script>alert('员工不存在');history.back();</script>" Response.End End If basesalary = CDbl(rs("BaseSalary")) rs.Close ' 实发 = 基本工资 + 奖金 - 考勤扣款 - 其他扣款 - 社保 net = basesalary + bonus - attendance - other - social If net < 0 Then net = 0 ' 当月已有记录则更新，否则插入，用 IF EXISTS 一条语句搞定 sql = "IF EXISTS(SELECT 1 FROM Salary WHERE EmpID=" & empid & " AND SalaryMonth='" & salarymonth & "') " & _ "UPDATE Salary SET AttendanceDeduct=" & attendance & ", Bonus=" & bonus & ", OtherDeduct=" & other & ", SocialSecurity=" & social & ", NetSalary=" & net & " WHERE EmpID=" & empid & " AND SalaryMonth='" & salarymonth & "' " & _ "ELSE INSERT INTO Salary(EmpID, SalaryMonth, AttendanceDeduct, Bonus, OtherDeduct, SocialSecurity, NetSalary) VALUES(" & empid & ",'" & salarymonth & "'," & attendance & "," & bonus & "," & other & "," & social & "," & net & ")" conn.Execute(sql) Response.Write "<script>alert('工资计算完成，实发：" & net & "');location='salary_list.asp?month=" & salarymonth & "';</script>" %>

这条 IF EXISTS 的 SQL 是典型的“覆盖式录入”写法，好处是同一个员工同一个月反复修改只保留一条记录，配合工资表上的 UNIQUE(EmpID, SalaryMonth) 约束形成双保险。CDbl 是把表单字符串转成双精度浮点，再用 decimal 字段存储时会做精度换算，计算页面上保留两位小数足够。

这里有个细节值得注意：实发工资算出来是负数，说明扣款加社保超过了应发，老系统普遍直接截断为 0。逻辑上能接受，但账面不平，规范的改法是把负值单独标记出来人工复核，不要静默截断。批量录入时，常见做法是先“批量初始化”当月工资记录——用一条 INSERT SELECT 把在职员工的基本工资都生成一遍，再逐项修改扣款，比逐条插入高效得多：

INSERT INTO Salary(EmpID, SalaryMonth, AttendanceDeduct, Bonus, OtherDeduct, SocialSecurity, NetSalary) SELECT EmpID, '202506', 0, 0, 0, 0, BaseSalary FROM Employee WHERE Status=1

注意这条语句只在当月还没有工资记录时执行，跑重复了会违反 UNIQUE 约束报错，所以在页面里要先查一下当月是否已有记录。

4. 工资查询、工资条与 Excel 导出：三个高频功能的实现

4.1 按月份和姓名过滤查询：SQL 条件拼接的顺序与写法

工资查询是使用频率最高的页面，一般默认展示最近一个月全员的工资，顶部提供月份下拉框和姓名输入框做过滤。条件拼接有个约定：每个条件都要判空，SQL 用 AND 连接时在开头加 1=1 做兜底，这是老 ASP 里最朴素的动态查询写法，逻辑清晰也好维护。

<% ' salary_list.asp 查询列表 Dim month, empname, whereclause, sql month = Trim(Request("month")) empname = Trim(Request("empname")) whereclause = " WHERE 1=1 " If Len(month) = 6 Then whereclause = whereclause & " AND s.SalaryMonth='" & month & "'" End If If empname <> "" Then empname = Replace(empname, "'", "''") whereclause = whereclause & " AND e.EmpName LIKE '%" & empname & "%'" End If sql = "SELECT e.EmpNo, e.EmpName, d.DeptName, s.SalaryMonth, s.BaseSalary, s.AttendanceDeduct, s.Bonus, s.OtherDeduct, s.SocialSecurity, s.NetSalary " & _ "FROM Salary s LEFT JOIN Employee e ON s.EmpID=e.EmpID " & _ "LEFT JOIN Department d ON e.DeptID=d.DeptID" & whereclause & " ORDER BY e.EmpNo" Set rs = conn.Execute(sql) ' 循环 rs 输出表格行，省略 HTML 渲染 %>

1=1 这个写法在性能上没有任何额外代价，SQL Server 的优化器会直接忽略恒真条件，它换来的是条件拼接的容错性：任何一个条件为空都不用调整 where 字符串的前后结构。LIKE '%" & empname & "%' 是包含匹配，注意通配符的位置决定匹配方式，前缀匹配 LIKE 'abc%' 能走索引，包含匹配走不了索引，但员工姓名查询这种数据量无所谓。拼接 SQL 时字段名前带上表别名（s. 和 e.），能避免两表字段重名时出现的歧义错误。

4.2 生成工资条：单人单月打印视图的做法

工资条本质上就是工资记录的格式化视图，老系统里通常是一个独立页面，URL 带 empid 和 month 参数，页面布局按纸面工资条的格式输出，用户直接用浏览器打印。工资条页的关键是不让用户手动输参数，而是从列表页的链接带过去，避免误操作。

<% ' payslip.asp?empid=1&month=202506 Dim empid, salarymonth empid = CLng(Request("empid")) salarymonth = Trim(Request("month")) sql = "SELECT e.EmpNo, e.EmpName, d.DeptName, s.SalaryMonth, s.BaseSalary, s.AttendanceDeduct, s.Bonus, s.OtherDeduct, s.SocialSecurity, s.NetSalary " & _ "FROM Salary s LEFT JOIN Employee e ON s.EmpID=e.EmpID " & _ "LEFT JOIN Department d ON e.DeptID=d.DeptID " & _ "WHERE s.EmpID=" & empid & " AND s.SalaryMonth='" & salarymonth & "'" Set rs = conn.Execute(sql) If Not rs.EOF Then ' 页面输出表格：应发项在上，扣款项在下，实发加粗 ' 只做展示，不做任何计算，金额全部取数据库存好的值 End If rs.Close : Set rs = Nothing %>

工资条页推荐只做展示不做计算，所有金额直接用工资表里存好的值渲染，原因有二：一是保证打印出来的工资条和列表页看到的一致，避免重复计算引发四舍五入的差异；二是如果计算逻辑以后要改（比如新增个税专项扣除），只改计算页，工资条页不用动。老系统里工资条页和计算页逻辑各写一份、改一处漏一处的教训很常见。打印时记得在页面里加 CSS 打印样式，把导航栏和按钮隐藏掉。

4.3 导出 Excel：设置响应头输出 HTML 表格的做法

老 ASP 系统导出 Excel 最省事的方案不是调用 COM 组件，而是把页面响应头改成 Excel 的 MIME 类型，让浏览器用 Excel 打开 HTML 表格。这个做法对格式控制弱，但零依赖、不装 Office 组件也能跑，中小企业的报表导出足够用。

<% ' export_excel.asp 导出当月工资表 Dim sql, rs Response.Buffer = True Response.Clear Response.ContentType = "application/vnd.ms-excel" Response.AddHeader "Content-Disposition", "attachment;filename=salary_" & month & ".xls" Response.Charset = "gb2312" ' 上面的响应头设置完成后，才能输出 HTML 内容 %> <html><head><meta charset="gb2312"></head><body> <table border="1"> <tr><td>工号</td><td>姓名</td><td>部门</td><td>实发</td></tr> <% ' 循环输出 rs 数据，写法与列表页相同，这里省略 %> </table></body></html>

这段代码有两个坑必须说明。第一个是 Response.Charset = "gb2312"，如果漏了这行，导出文件在 Excel 里打开就是乱码，因为 HTML 表格本身没有编码声明时，浏览器按响应头处理；第二个是 Content-Disposition 里的文件名如果是中文，需要做 URL 编码，否则下载时文件名是乱的。用这种方案导出的 .xls 实际是 HTML 文档，Excel 打开时会弹格式不匹配的提示，点确定即可，不影响看数据。

如果一定要导出真正的 .xls 或 .xlsx，就得引入第三方组件，常见方案是服务端生成 XML 电子表格格式（SpreadsheetML）再输出，但工作量和维护成本高一个量级。我的建议是：内部报表用 HTML 导出，需要交给外部系统解析的文件才考虑真 Excel 格式。

5. 部署与避坑：IIS 配置、编码乱码与五个经典翻车现场

5.1 IIS 上部署 ASP 工资系统的最小步骤

拿到一个源码包，最快跑起来的路径是固定的。以 Windows Server 2012 加 IIS 8 为例，步骤是：先确认 IIS 的“应用程序开发功能”里 ASP 已勾选，然后新建网站或应用程序池，物理路径指向源码解压目录，把数据库还原到 SQL Server，改 conn.asp 里的连接串，最后浏览器访问首页。数据库还原用 SQL Server Management Studio，右键“数据库”→ “还原数据库”，选“源设备”指向 .bak 文件。老版本备份还原时如果报“数据库正在使用”，先执行 ALTER DATABASE 设置单用户模式再还原：

# 以管理员身份运行 PowerShell，打开 ASP 经典引擎功能 Install-WindowsFeature Web-ASP, Web-Asp-Net45

部署完成后第一个验证动作不是点业务功能，而是直接访问一个空白的 test.asp 页面，内容就一行 <%= 1+1 %>，输出 2 说明 ASP 引擎正常，剩下的问题才是业务代码层面的。这个习惯能帮你把“环境没配对”和“代码有 bug”两类问题分开定位。

5.2 五个经典踩坑记录：现象、原因与解决

这一节集中写维护这类系统时反复见到的五个问题，按现象、原因、解决的顺序记。每一条都对应一次真实翻车，照着排查能省不少时间。

坑一：页面中文全部变成问号或乱码

现象：源码包里的页面直接在浏览器打开，中文全乱，数据库读出来的员工姓名也是问号。

原因：老 ASP 源码普遍使用 GB2312 编码，页面头部缺少 <%@ CodePage=936 %> 声明时，IIS 默认按 UTF-8 解析；另外数据库表字段如果是 VARCHAR 类型存中文，连接串里没加编码相关处理也会乱。

解决：在每个 .asp 页面第一行加 <%@ Language="VBScript" CodePage=936 %>，文件本身以 ANSI 编码保存；字段类型从 VARCHAR 改成 NVARCHAR 后重新录入数据。注意改完 CodePage 要重启应用程序池才生效。

坑二：页面 500 错误，事件日志提示父路径问题

现象：IIS 上一跑就 500，页面完全空白，浏览器显示 HTTP 500 或 404.3。

原因：最常见的两种——机器上没装 ASP 功能；源码里用了 这种上级目录引用，而 IIS 默认禁止父路径。

解决：确认安装 ASP 功能后，在 IIS 的 ASP 设置里把“启用父路径”设为 True。对需要层级 include 的老源码这是必选项。改成相对路径 include 也行，但改动量大，优先调 IIS 设置。

坑三：数据库连接失败，报“未找到提供程序”或“无法连接”

现象：本机调试一切正常，换到服务器后页面全部报数据库错误，错误描述是 Provider 相关或连接超时。

原因：服务器上的 SQL Server 没开 TCP/IP 协议；或者 64 位系统下应用程序池没有启用 32 位，而老的 SQLOLEDB 驱动在某些环境下需要 32 位。

解决：在 SQL Server 配置管理器里启用 TCP/IP 并重启服务；在 IIS 应用程序池高级设置里把“启用的 32 位应用程序”设为 True；连接串里 Data Source 用 IP，不要用服务器名，避开 DNS 解析问题。

坑四：工资查询条件带单引号，整页报 SQL 语法错误

现象：在姓名输入框里输入“王'五”（含单引号），页面直接报 SQL 语法错误。

原因：典型的 SQL 注入触发，字符串拼接没过滤单引号，输入内容闭合了 SQL 语句。

解决：紧急修法是在所有从 Request 取值的变量赋值后执行 Replace(variable, "'", "''")。彻底修法是改用 ADO Command 的 Parameters 集合传参。对老系统，我通常先做全站批量替换做紧急加固，再对登录、工资计算等核心入口改成参数化。

坑五：月份查询结果不对，选的 6 月查出别的月

现象：查询某月工资时，月份下拉选 6 月，查出来的是其他月份的数据。

原因：SalaryMonth 如果用日期类型存储，而代码用字符串 '2025-06' 直接比较，SQL Server 隐式转换受区域日期格式影响，某些区域设置下把 '06' 解析成第 6 天而不是 6 月。

解决：最省事的是查询端传完整日期或用 LIKE '2025-06%'；更根治的做法是把月份列改成 CHAR(6) 存 '202506'，并同步改计算页和查询页的传参格式。这种类型不一致的问题在老系统里最隐蔽，因为本机测试环境永远是默认区域设置，上了服务器才暴露。

6. 二次开发要动的三处：会话超时、密码加盐与自动备份

接手老系统后的第一周，我通常只动三处，改动量小但能把运行稳定性拉高一截。第一处是会话超时。IIS 里 ASP 的 Session 超时默认 20 分钟，工资录入页面经常一填就是半小时，点保存时 Session 失效被踢回登录页，刚录的数据全丢。在 IIS 的 ASP 设置里把“会话属性 → 超时”调到 60 分钟，或者在公共文件里直接写代码，后者更好，因为跟着源码走，换服务器不用再配一次：

<% ' 放在 conn.asp 里，全局生效 Session.Timeout = 60 %>

第二处是老系统的 MD5 密码。老源码用纯 MD5，彩虹表一查就破。最小改动是把密码存成加盐的 MD5：在登录和改密两处把 MD5(password) 改成 MD5(username & password & "SALT2025")，已有数据的密码需要重置。固定盐的强度有限，但至少挡住了彩虹表直查，成本极低。

第三处是数据库自动备份。工资数据是财务级数据，丢一个月就乱套。能用 SQL Server 代理建维护计划最好；没有代理权限就用 Windows 计划任务跑 SQLCMD，备份文件名带上日期才能留多个版本：

sqlcmd -S 127.0.0.1 -U sa -P "sa123" -Q "BACKUP DATABASE SalaryDB TO DISK='D:\backup\SalaryDB_' + REPLACE(CONVERT(VARCHAR(10),GETDATE(),120),'-','') + '.bak' WITH INIT"

命令里的 REPLACE 把日期里的横杠去掉，拼出 SalaryDB_20250607.bak 这种文件名。WITH INIT 是覆盖同名文件，如果想让备份只保留最近四周，就在计划任务里加一个删除三个月前备份文件的脚步，别让磁盘被备份撑爆。备份文件建议放在非系统盘，和数据库文件分离，防止磁盘故障时一起丢。

这三处改完，系统的可用性基本够日常跑。我更想说的一个习惯是：任何一次改动都先在测试库上还原一份 .bak 再动手。老 ASP 系统没有版本控制的概念，源码包就是唯一真相，改之前留个备份是这套技术栈里最重要的后悔药。我自己维护这类系统几年，最大的教训就是不要相信“这个页面没人用”的判断，每一行看似死代码的地方都可能在下个发薪日突然被点开。先备份、小步改、勤验证，老系统也能稳稳地跑下去。希望这篇笔记能帮到你，尤其是第一次接盘老 ASP 工资系统的时候。

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