企业官网建设流程全解析

简介：面向Web开发与数据库学习者的企业工资管理系统源码，基于ASP+SQL技术栈实现薪资核算、员工考勤、报表统计等核心业务。压缩包内共97个文件，以ASP页面为主（67个），辅以CSS样式、GIF/JPG图标及SQL数据库文件（.mdf/.ldf），整体仅689KB，结构清晰便于本地部署与二次开发。目前已有421人学习下载。学习该源码可深入理解ASP与数据库的交互方式、SQL查询设计及Web应用业务逻辑，同时涵盖防SQL注入等安全实践；从员工信息管理、工资项目配置到个税计算与权限控制，适合初学者掌握动态网站开发，也为企业薪资系统定制提供完整参考。

1. 企业工资管理系统源码ASP+SQL：一套能直接跑的WEB工资台账

企业工资管理系统源码ASP+SQL，听起来像是上个时代的产物，但真要你把它部署起来跑通工资计算流程，不少人会卡在环境配置和数据库脚本上。这份源码走的是经典ASP加SQL Server的组合，整套WEB流程覆盖员工档案、部门设置、工资项目、月度计算和统计查询。它不花哨，却把工资管理最核心的“算出实发工资”这条路完整捋了一遍。适合要接手老系统的人，也适合拿来练手的开发者。你不需要从零建模，改改数据表结构、调一调页面逻辑，就能交出一个能用的系统。关键是搞清楚源码里哪些地方能改、哪些地方一改就崩。

先说明一点：经典ASP项目不像现在的框架有标准脚手架，它的数据库连接、权限判断、页面逻辑经常混在一起，但恰恰因为结构简单，反而容易拆开看。下面按部署、数据表、计算逻辑、权限和避坑的顺序，把这份源码完整走一遍。

2. 先把环境拉起来：IIS与SQL Server的版本搭配与部署

2.1 经典ASP为什么还要选IIS：版本取舍

经典ASP必须在IIS上运行，这一点没有太多讨价还价的余地。你可以用Windows 10/11自带的IIS 10，也可以找一台Windows Server 2008跑IIS 7，区别主要体现在默认配置上：IIS 6/7默认就支持ASP脚本，IIS 7.5之后默认反而是禁用ASP的，需要手动开启。我一般优先选SQL Server 2008 R2配IIS 7.0/7.5，因为这份源码里的老SQL写法在那时候的兼容性最好，部署后直接改连接串就能跑。

先装IIS：打开“控制面板 -> 程序 -> 启用或关闭Windows功能”，勾选“Internet信息服务”下面的“Web管理工具”和“万维网服务 -> 应用程序开发功能 -> ASP”，然后确认。装完后浏览器访问http://localhost，能打开IIS默认页面就说明WEB服务器起来了。接着把源码目录整个拷到C:\inetpub\wwwroot\SalaryWeb，在IIS管理器中右键该目录选择“转换为应用程序”，应用程序池建议选DefaultAppPool或Classic .NET AppPool，并确保“启用32位应用程序”为True。很多老ASP页面里的组件是32位DLL，不开启的话会报“服务器组件”类错误。

这里有个常见的权限改法：页面执行时反复报权限问题，先看应用程序池的“进程模型 -> 标识”。老源码经常需要给IIS_IUSRS用户添加目录的“读取和执行”权限，写日志的目录单独加“写入”权限，不要图省事把整个站点设置成完全控制。这个习惯能减少上线后一半的权限排查时间。

2.2 连接串与数据库部署：conn.asp 里那几行是关键

经典ASP项目通常用一个固定的conn.asp或db.asp保存数据库连接。下面是这个资源里最常见的写法：

<% Dim conn, connStr connStr = "Provider=SQLOLEDB.1;Data Source=.;Initial Catalog=SalaryDB;User ID=sa;Password=你的密码;Persist Security Info=True" Set conn = Server.CreateObject("ADODB.Connection") conn.Open connStr %>

四个参数最关键：Data Source是数据库实例名，点代表本地默认实例；命名实例要写成计算机名\SQLEXPRESS。Initial Catalog是数据库名，必须与SQL Server里建的库名一致。User ID和Password建议用一个最小权限的数据库账号，不要直接挂sa——虽然老源码里多半就是sa，但正式环境里尽量不要沿用。Provider=SQLOLEDB.1是OLE DB提供程序，如果SQL Server版本到了2012以上，也可以换成SQLNCLI11或MSOLEDBSQL，但老系统里保留原提供程序往往最稳，换Provider很容易触发“未指定的错误”。

数据库这边先建一个SalaryDB库，再把源码里带的SQL脚本按顺序执行。如果源码没带脚本，就用SSMS手工方式：右键“数据库”->“新建数据库”->输入SalaryDB，然后在“选项”里把“兼容级别”设为SQL Server 2008 (100)，避免新版本数据库默认行为差异导致页面报错。执行脚本时不要整个文件一次性跑，有些老脚本没有用GO切分，中途报错容易让人误以为是源码问题；我一般会按“建表——基础数据——存储过程”分三段执行，哪段出了问题一目了然。

2.3 初始化基础数据：没有账套数据，登录页都进不去

工资系统常见的第一个障碍是登录页能打开但登录不进去，原因是数据库里没有用户表数据。先执行一段初始化脚本：

USE SalaryDB; GO IF NOT EXISTS (SELECT 1 FROM sys.tables WHERE name='SysUsers') BEGIN CREATE TABLE SysUsers( UserID INT IDENTITY(1,1) PRIMARY KEY, UserName NVARCHAR(50) NOT NULL, Password NVARCHAR(50) NOT NULL, RoleName NVARCHAR(20) DEFAULT '普通操作员' ); END; INSERT INTO SysUsers(UserName,Password,RoleName) SELECT 'admin','admin123','系统管理员' WHERE NOT EXISTS (SELECT 1 FROM SysUsers WHERE UserName='admin');

这里没有给密码加密，因为很多ASP老源码默认就是明文比对。模拟环境下可以直接用，真要上生产，请把登录脚本改成MD5或SHA1比对。还有一个容易被忽略的点：sys.tables这种查询在SQL Server 2000里不能用，如果你的库是2000，改成SELECT name FROM sysobjects WHERE xtype='U'。这个兼容性问题就是老项目的现实，不是看不懂源码的问题，是环境年龄差的问题。

3. 拆开工资计算的主流程：表结构、ASP逻辑与页面联动

3.1 三张核心表：员工、工资项目、工资记录

要把工资算出来，先要理解这套系统的数据底座。拆开之后会发现核心就是三张表：Employees存员工静态信息，PayItems存工资项目的口径，SalaryRecords存每个月每个员工的计算结果。三者的关系是：员工表是主数据，工资项目表是字典，工资记录表以EmpID + PayMonth为唯一维度记录月度结果。下面是最小可用的建表脚本：

CREATE TABLE Employees( EmpID INT IDENTITY(1,1) PRIMARY KEY, EmpNo VARCHAR(20) NOT NULL UNIQUE, EmpName NVARCHAR(50) NOT NULL, DeptID INT NOT NULL, BaseSalary DECIMAL(10,2) DEFAULT 0 ); CREATE TABLE PayItems( ItemID INT IDENTITY(1,1) PRIMARY KEY, ItemName NVARCHAR(30) NOT NULL, ItemType VARCHAR(10) NOT NULL, -- 'income'收入项 / 'deduction'扣款项 CalcBase VARCHAR(20) -- 按固定值、按基本工资比例等 ); CREATE TABLE SalaryRecords( RecordID INT IDENTITY(1,1) PRIMARY KEY, EmpID INT NOT NULL REFERENCES Employees(EmpID), PayMonth CHAR(6) NOT NULL, BaseSalary DECIMAL(10,2) DEFAULT 0, Bonus DECIMAL(10,2) DEFAULT 0, OvertimePay DECIMAL(10,2) DEFAULT 0, Insurance DECIMAL(10,2) DEFAULT 0, Tax DECIMAL(10,2) DEFAULT 0, NetSalary DECIMAL(10,2) DEFAULT 0, UNIQUE(EmpID, PayMonth) );

注意字段类型：金额一律用DECIMAL(10,2)，不要用FLOAT；PayMonth用CHAR(6)存202502这种格式，比用DATETIME更好排序和比较。工资项目表里ItemType区分收入项和扣款项，方便后面做统计。这三张表建好后，整个系统的数据关系就立住了：工资项目表决定有哪些收入项和扣款项，工资记录表把每个员工的结果固化下来，统计报表直接查记录表，不用每次重新计算。

3.2 服务端计算逻辑：加班费、社保与个税怎么在ASP里落地

页面录入考勤和补贴后，ASP脚本拿到表单值，然后逐项计算。以一个月度工资录入页为例，简化后的核心逻辑如下：

<% empId = CLng(Request.Form("empId")) baseSalary = CDbl(Request.Form("baseSalary")) bonus = CDbl(Request.Form("bonus")) overtime = CDbl(Request.Form("overtime")) insuranceRate = 0.1 ' 社保比例，实际项目里按当地政策配置 insurance = Round(baseSalary * insuranceRate, 2) gross = baseSalary + bonus + overtime tax = 0 taxBase = gross - insurance - 5000 If taxBase > 0 Then tax = Round(taxBase * 0.03, 2) ' 简化税率 End If netSalary = gross - insurance - tax sql = "INSERT INTO SalaryRecords(EmpID,PayMonth,BaseSalary,Bonus,OvertimePay,Insurance,Tax,NetSalary) VALUES(" & _ empId & ",'" & PayMonth & "'," & baseSalary & "," & bonus & "," & overtime & "," & insurance & "," & tax & "," & netSalary & ")" conn.Execute sql %>

这里有三个容易被忽略的点。第一，Request.Form取到的值是字符串，必须先做类型转换，CLng和CDbl是常用转换函数，但遇到空表单值会直接报“类型不匹配”，所以我在转换前会加IsNumeric判断，后面避坑章节细说。第二，社保那部分用了固定比例，真实项目里应该从PayItems表按CalcBase取值，再乘以对应基数，而不是硬编码。第三，个税计算这里只用了3%一档，把它当作演示逻辑，上生产前一定要按当时的个税表分段计算。这段代码最能体现ASP老系统的现状：逻辑直白，参数都裸在页面里，改起来方便，但正因为太方便，容易改出问题。

3.3 页面查询与分页：用RecordSet翻页并不难，但容易翻车

工资记录最好按月检索，所以列表页必须支持分页。经典ASP里分页依赖RecordSet的三个属性：PageSize、AbsolutePage和PageCount。典型写法如下：

<% Set rs = Server.CreateObject("ADODB.RecordSet") sql = "SELECT EmpName, PayMonth, BaseSalary, Bonus, OvertimePay, Insurance, Tax, NetSalary FROM v_SalaryDetail ORDER BY PayMonth DESC" rs.Open sql, conn, 1, 1 rs.PageSize = 20 page = CLng(Request.QueryString("page")) If page < 1 Then page = 1 If page > rs.PageCount Then page = rs.PageCount rs.AbsolutePage = page PageCount = rs.PageCount %> <table border="1"> <% For i = 1 To rs.PageSize If rs.EOF Then Exit For Response.Write "<tr><td>" & rs("EmpName") & "</td><td>" & rs("NetSalary") & "</td></tr>" rs.MoveNext Next %> </table>

rs.Open sql, conn, 1, 1这行里的两个1分别代表CursorType和LockType。分页至少要游标类型adOpenKeyset(1)，否则AbsolutePage会报错或返回-1。这里用到的v_SalaryDetail是一个视图，实际项目里可以把员工姓名、部门等字段关联好；如果源码里没有这个视图，直接用JOIN查询也可以。分页翻车最常见的原因是游标类型用了默认的adOpenForwardOnly（0），处理方式就是保持游标类型为1或3。

4. 登录与权限：ASP+SQL里的Session角色控制怎么做

4.1 登录校验：别只看密码相等，还要处理Session失效

登录页是所有后台系统的正门。ASP里一般用Session存登录态，用户表就是前面建的SysUsers。登录脚本的常规写法：

<% username = Trim(Request.Form("username")) pwd = Trim(Request.Form("password")) sql = "SELECT UserID, UserName, RoleName FROM SysUsers WHERE UserName = '" & Replace(username,"'","''") & "' AND Password = '" & Replace(pwd,"'","''") & "'" Set rs = conn.Execute(sql) If Not rs.EOF Then Session("UserID") = rs("UserID") Session("UserName") = rs("UserName") Session("RoleName") = rs("RoleName") Response.Redirect "main.asp" Else Response.Write "用户名或密码错误" End If %>

这段代码里用了Replace(username,"'","''")，是防止单引号导致SQL语法错误。但坦率讲这只是最基础的转义，治标不治本。如果要改造成安全版本，应该用Command对象配合参数查询，把用户名和密码作为参数传入，不要拼进SQL字符串。Session的坑在于：IIS默认20分钟超时，用户打开页面超过这个时间再操作，Session("UserID")就变成空值。很多老系统在页面头只做了“是否为空”判断，业务代码里继续读Session，一旦超时就会报变量未定义。我一般会在受保护页面的顶部统一加一个检查文件check_login.asp：

<% If Session("UserID") = "" Then Response.Redirect "login.asp?msg=timeout" End If %>

页面顶部用<!-- #include file="check_login.asp" -->引入，这样权限校验就不会漏。这也是这份源码里最值得仿照的模式：把通用逻辑抽到include文件里，而不是每个页面复制一遍。

4.2 角色菜单与数据权限：同一套代码，不同用户看到不同范围

有了Session("RoleName")，菜单显示就能动态控制。比如页面顶部导航：

<% If Session("RoleName") = "系统管理员" Then Response.Write "<a href='user_admin.asp'>用户管理</a> " End If If Session("RoleName") <> "普通操作员" Then Response.Write "<a href='salary_input.asp'>工资录入</a> " End If Response.Write "<a href='salary_query.asp'>工资查询</a>" %>

这层的重点是“控制逻辑要放在服务端”，不要只在前端隐藏按钮。否则用户直接在地址栏输入user_admin.asp，一样能打开页面。稳妥做法是在check_login.asp里同时判断当前页面是否在角色黑名单里，或者给菜单项对应的页面各自加上权限判断函数。数据权限同理：普通操作员只能看本部门数据，那工资查询页的SQL就要拼接WHERE DeptID = Session("DeptID")。老系统的通病是页面里SQL写得太随意，改角色时只改菜单，忘了数据过滤，结果部门之间数据全裸奔。

4.3 密码安全：把明文改造成MD5比想象中麻烦

很多ASP源码登录成功用的是明文比对。改造密码第一步：在SysUsers表加一个PasswordHash字段，登录时把用户输入的密码做MD5后比对。经典ASP里做MD5通常要引用md5.asp文件，这个文件来自公开算法实现，运行时会遇到两个小坑：一是文件编码必须是ANSI，二是页面必须声明CodePage=65001才不会计算出来乱码。改造后的登录脚本大致是：

<% inputPwd = md5(Trim(Request.Form("password"))) sql = "SELECT UserID, RoleName FROM SysUsers WHERE UserName = '" & Replace(username,"'","''") & "' AND PasswordHash = '" & inputPwd & "'" %>

改完之后别忘了把已有账号的密码批量刷一遍，用一段SQL一次性把明文转成哈希。推荐的做法是新建一个字段，而不是直接改原字段，这样万一脚本出错，还可以拿旧密码恢复。如果你把网上的md5.asp直接拖进项目，不检查它依赖的BytesToHex函数命名，很容易在本地测试时报“缺少对象”。我建议先在独立页面里调用一次函数做冒烟测试，再接入登录页。这个改造说难不难，但每一步都要留好后悔药。

5. 避坑指南：老ASP项目翻新最容易踩的五个坑

5.1 数据库连接失败：报“未指定的错误”先看Provider

现象：页面打开后报ADODB.Connection 错误 '800a0e7a' 未指定的错误，或者干脆显示500。

原因：八成是连接串里的Provider=SQLOLEDB.1在当前系统上没有被正确注册。Windows 10/11、Server 2016以上默认可能没有旧版OLE DB驱动，也可能是SQL Server实例名和连接串对不上。

解决：先打开“计算机管理 -> ODBC数据源(64位/32位)”，看有没有SQL Server或SQL Server Native Client驱动。没有的话就安装对应驱动，或者把连接串改成新驱动，例如Provider=MSOLEDBSQL;Data Source=.;Initial Catalog=SalaryDB;User ID=sa;Password=...。两个驱动在字符串连接语法上有细微差别，改完先做一次简单查询验证，不要在AJAX接口里排错。我遇到过一个人改连接串只改了Provider，后面的Data Source没动，结果连本地库都连不上，白折腾半天。

5.2 中文乱码：代码页、数据库排序规则和Response.Charset三者对齐

现象：页面上工资项目名称、员工姓名全是???，数据库里也存成了乱码。

原因：经典ASP页面默认代码页是936（简体中文GBK），数据库表如果是Latin1_General排序规则，VARCHAR字段存中文就丢字；还有页面没有设置Response.Charset。

解决：统一三处：页面顶部加<%@ Language="VBScript" CodePage=936 %>和<% Response.Charset="gb2312" %>；建表时指定NVARCHAR，字符串常量前加N；数据库排序规则设为Chinese_PRC_CI_AS。如果已经在错误排序规则的库里建了表，常见做法是ALTER DATABASE SalaryDB COLLATE Chinese_PRC_CI_AS，改完重建索引，否则查询排序可能报错。这个坑很容易被忽略，因为本地开发环境代码页恰好是中文，部署服务器却是英文系统，页面就乱了。排查顺序永远是“先看库里存的是什么，再看页面显示的是什么”。

5.3 IIS7以上跑ASP报404.3或500.100

现象：在Windows Server 2008以上版本部署，访问.asp页面报404.3或500.100，HTML页面正常。

原因：IIS 7之后ASP功能默认没有启用，或者“ISAPI筛选器”配置不完整。

解决：打开IIS管理器，选中站点，在“功能视图”里双击“ASP”，把“启用父路径”设为True，“行为”里的“启用ASP服务端调试”按需打开。如果还不行，到“控制面板 -> 启用或关闭Windows功能”里勾选“ASP”。做完重启IIS，执行iisreset /restart。另一个隐蔽点：如果页面用了#include file="../conn.asp"，父路径没开启会报“无法包含文件”，别急着改源码，先改这个开关。这个坑几乎每个接手老项目的新人都会遇到，我当年也在上面白耗过一个下午。

5.4 SQL Server登录失败：sa账号进不去，或只能Windows认证

现象：页面提示登录失败，用户 'sa' 登录失败，而SSMS能连。

原因：SQL Server实例默认可能只开了“Windows身份验证模式”，而ASP连接串用的是SQL账号。

解决：在SSMS实例属性里，选择“安全性”，改成“SQL Server和Windows身份验证模式”，然后重启SQL Server服务。接着检查sa账号是否被禁用，老系统的安全设置经常把sa锁了。我一般会新建一个web_user账号，只授db_datareader和db_datawriter权限，连接串里用它，避免把sa密码写在ASP源码里。这样即使页面文件被下载，数据库也不是裸奔的。权限给得太宽是这类老项目最常见的安全问题，能少给就少给。

5.5 表单提交后报800a000d：类型不匹配大多因为空字段

现象：工资录入页填完数据点保存，页面报Microsoft VBScript 运行时错误 '800a000d'，类型不匹配。

原因：页面里某个Request.Form字段为空，CDbl("")或CLng("")直接触发类型不匹配。

解决：转换前增加校验。常见做法是封装一个函数：

Function ToNum(val, defaultVal) If IsNumeric(val) Then ToNum = CDbl(val) Else ToNum = defaultVal End If End Function

凡是涉及金额和数量的字段，统一用ToNum(Request.Form("xxx"), 0)替代裸CDbl。这样既保留老代码的结构，又避免临时工提交空表单把页面打挂。另一个隐藏点：Request.Form字段名和HTML控件name不一致，比如按钮name="submit"占用了某个查询字段，也会取到“提交”两个字导致类型不匹配，排查时先输出Request.Form所有键值，再逐项核对。

6. 进阶验证：给工资系统加一个按部门汇总的导出CSV功能

源码能跑起来只是开始，真正考验你是否看懂项目的是扩展能力。我习惯拿“导出工资汇总表”作为验证动作：因为导出功能涉及SQL聚合、Response输出、编码处理三件事，恰好覆盖老系统改造的常见难点。

先在SQL里把汇总查出来，这里用GROUP BY加SUM：

SELECT d.DeptName, COUNT(DISTINCT s.EmpID) AS EmpCount, SUM(s.NetSalary) AS TotalNet FROM SalaryRecords s INNER JOIN Employees e ON s.EmpID=e.EmpID INNER JOIN Departments d ON e.DeptID=d.DeptID WHERE s.PayMonth='202502' GROUP BY d.DeptName;

然后在ASP页面里输出CSV，关键是两个细节：文件头要用Response.ContentType="text/csv"，并且为了Excel打开不出现中文乱码，前面加上BOM字节。

<% Response.ContentType = "text/csv" Response.Charset = "utf-8" Response.Write Chr(255) & Chr(254) ' UTF-8 BOM Response.Write "部门,人数,实发合计" ' RS循环输出... %>

这里Chr(255) & Chr(254)是BOM的一种写法，如果发现Excel打开还是乱码，可以试Response.BinaryWrite方式改写。行政同事要的是Excel能正常打开，这一点不能想当然。我第一次做这个功能时直接Response.Write拼了一堆逗号，结果Excel打开全乱码，后来才意识到是老代码页和CSV编码冲突。从那以后我每次给老ASP项目加导出功能，都强制走一遍“先聚合、再输出、最后验编码”三步。这份源码本身就是一个可以拿去做部门汇总、工资条导出、月度报表的底子，下载后按第2章流程把环境和数据库初始化好，再按这个思路扩展就行。希望帮到你。

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