企业官网建设流程全解析

简介：这套ASP+ACCESS酒店预定管理系统以完整项目压缩包形式提供，面向Web开发初学者、计算机专业毕业生及需要快速搭建酒店预订演示项目的开发者。系统以ASP作为后端脚本环境，配合ACCESS数据库完成用户注册登录、房间浏览、在线预订、订单管理等核心功能，覆盖从需求分析、系统设计、编码实现到测试维护的完整开发链路。压缩包为zip格式，整体大小约775KB，包含开题报告、源代码与论文三部分内容，便于直接查阅技术方案、运行调试或作为毕业设计参考资料。目前已有25人学习下载，适合正在学习VBScript脚本编写、SQL数据操作及Session会话管理的读者。通过该资源可了解小型Web信息管理系统的分层实现思路，掌握ASP+ACCESS组合下的权限管理、数据交互与界面布局方式，为后续独立开发类似管理系统提供可参考的工程模板。

1. 一套20年前的技术栈，为什么现在还有人拿它做酒店预定系统

ASP 加 ACCESS 这个组合，放到今天看几乎像是古董：ASP 早在多年前就停止迭代，ACCESS 也被微软官方边缘化。但你只要逛过毕业设计相关的话题区就会发现，ASP+ACCESS 酒店预定管理系统仍然是出现频率极高的项目包。原因很直接：它的技术闭环完整、数据库是单文件、源码足够短，一个学生从看懂到改完，两到三周就能搞定，而且能同时交付开题报告、源代码和论文三样东西。

这篇笔记要讲的就是这类项目包背后的真实工程逻辑：系统需求怎么拆、ACCESS 数据库怎么设计和连接、ASP 页面之间怎么跳转和传值、在 Windows 上怎么部署不会翻车，以及答辩前哪些坑必须提前踩一遍。适合正在做课程设计或毕业设计的同学，也适合想快速搭一个内部演示用的后台管理系统的开发者。

2. 拆解酒店预定管理系统的功能与页面：先把角色和流程定住

做这类系统，最常见的问题是一上来就写代码，写到一半发现页面跳转乱成一团、角色权限分不清、订单状态没人维护。我一般会先花半天把角色和流程在纸上画清楚，再开数据库表。ASP 项目没有现代框架帮你强制分层，所有页面都是扁平的 .asp 文件，前期不把边界拆清楚，后面就是无穷无尽的改页面逻辑。

2.1 三类使用者和三条业务主线

酒店预定系统无论怎么改版，核心角色就三类：未登录访客、注册用户、后台管理员。访客能浏览客房、查看房型价格，想下单就得注册登录；注册用户能提交订单、查看自己的订单记录；管理员负责维护房型客房数据、处理订单状态、管理用户。

业务主线也只有三条：客房展示与查询、在线预订下单、后台管理与订单处理。凡是能在这三条线之外的功能，比如留言板、友情链接、网站公告，都属于后加的装饰性模块。做开题报告时，功能模块图画这三条线就够了，不要画得花里胡哨，答辩老师通常会顺着核心流程问，不会揪着边角功能问。

权限控制落在 Session 上。访客没有 Session，注册用户登录后写入 Session，管理员登录后写入另一个标记。每个需要登录的页面顶部检查 Session，没登录就跳回登录页。ASP 里没有中间件拦截这回事，页面级检查是最稳妥的，也是论文里能写清楚的逻辑。

2.2 页面清单与流转关系：从首页到下单页再到后台

页面数量不需要多，十几二十个足矣。前台通常有：首页（房型推荐）、客房列表页、客房详情页、登录页、注册页、下单页、我的订单页、订单详情页。后台则有：管理员登录页、客房管理页、房型管理页、订单管理页、用户管理页。两类页面可以用文件夹区分，比如前台放根目录，后台放 admin 文件夹。

页面之间的流转关系是：访客从首页或客房列表进入详情页，点击预订跳到登录页，登录或注册后回到下单页，填写入住日期和联系人信息后提交订单；管理员从后台入口登录，进入订单管理，对订单做确认、入住、退房操作。这套流转关系要写成文字描述放进开题报告的用例说明里，同时也是你测试时的功能清单。

我见过不少半成品项目，客房列表页做出来了，但没有详情页，预订按钮直接跳到登录页，下单页又是几个字段硬拼。这种断档就是需求没拆干净的表现，答辩时被问"从点击预订到订单入库中间经历了哪几步"，答不出来就露馅。所以在写代码之前，先用一张表把每个页面文件、它的入参来源、出去的目标页列出来。

页面流转的过程中，参数传递存在三种方式：表单 POST 提交、URL 的 QueryString 传递、Session 保持登录态。客房 ID 这类参数用 QueryString 从列表页带到详情页再带到下单页，用户身份信息放在 Session，订单数据只能从表单 POST 进来。这个约定在写代码时严格遵守，能少掉一大半参数错乱的问题。

2.3 为什么选 ASP+ACCESS 而不是 PHP+MySQL：选型理由要写进开题报告的"技术路线"一节

现在新写系统，很少有人主动选 ASP+ACCESS。但在课程设计和毕业设计场景下，这个组合恰恰是最省事的：不需要单独安装数据库服务，ACCESS 就是一个 .mdb 文件，打包提交时连数据一起带走；IIS 自带 ASP 支持，不需要像 PHP 那样配置解释器；整个项目的代码量通常在几千行，答辩前能读完整套源码。这些理由不需要回避，开题报告里直接写清楚"本系统采用 ASP 与 ACCESS 作为技术栈，目的是在受控演示规模下完整实现酒店预订的信息化管理流程"，比硬吹高性能要诚实得多。

ACCESS 的定位是桌面级数据库，最大短板是并发能力。酒店预定系统在学校演示、机房测试这种场景下，同时在线人数基本不超过几十人，ACCESS 完全扛得住。你自己心里要有数：它的锁库机制在多人同时写时会报错，所以论文里不要写"支持高并发"这种话，写成"适用于中小规模酒店的前台预订管理"才是准确的。选型这事，不是选最强的，是选够用且你能讲透的。

3. 把数据库落到 .mdb：建表、连接串与公共包含文件

数据库设计是这套系统能不能跑起来的关键。ACCESS 的数据类型和 SQL Server 有差异，有些在 MySQL 里写得很顺的语句，在 Jet SQL 里跑不通。这一章直接给出建表语句和连接串，你照着建库就能往下走。

3.1 数据库表设计：五张表对应的主键、外键与状态字段

一个完整的酒店预定管理系统，数据库里至少要有五张表：用户表、房型表、客房表、订单表、管理员表。用户表存注册用户基本信息；房型表存标准间、大床房这类分类和对应价格；客房表存具体的房间号，每一间挂在某个房型下面；订单表记录用户订了哪间房、入住和退房日期、订单金额和状态；管理员表单独存后台登录账号。

字段设计上，我建议每张表都加一个自增主键，ACCESS 里用"自动编号"类型。客房状态、订单状态用数字表示，0 表示空闲或待确认，1 表示占用或已确认，不用字符串，字符串在查询和排序时容易出问题。金额字段用"货币"类型，日期字段用"日期/时间"，文本字段注意长度，用户名密码给 50 就够了，别默认 255 一拉到底。

订单表里除了房间号，还要冗余一个"预订时价格"字段。这个字段很多人会忽略，导致订单表只存了房间 ID，详情页要现查房型价格。一旦后台改了价，历史订单的金额就跟着变，账就对不上。下单那一刻把价格快照存进订单表，这是减法也是行业的常规做法。订单的表结构大致是：订单 ID、用户 ID、房间 ID、房型名称快照、入住日期、退房日期、预定价格快照、订单状态、下单时间。

3.2 在 Access 里执行建表 SQL：Jet SQL 对数据类型的限制

ACCESS 支持通过 SQL 视图执行建表语句，但它的 SQL 方言和标准 SQL 有差异。自增字段要用 COUNTER 或直接在设计视图中把字段类型选为"自动编号"。文本字段用 TEXT(50)，数字用 INTEGER 或 LONG，日期用 DATETIME，金额用 MONEY。下面这段建表脚本可以直接复制到 ACCESS 的查询设计器里运行：

CREATE TABLE tb_user ( user_id INTEGER PRIMARY KEY, user_name TEXT(50) NOT NULL, user_pwd TEXT(50) NOT NULL, real_name TEXT(50), phone TEXT(20), reg_time DATETIME ); CREATE TABLE tb_roomtype ( type_id INTEGER PRIMARY KEY, type_name TEXT(50) NOT NULL, price MONEY NOT NULL, remark TEXT(200) ); CREATE TABLE tb_room ( room_id INTEGER PRIMARY KEY, room_no TEXT(20) NOT NULL, type_id INTEGER, floor_no TEXT(10), room_status INTEGER DEFAULT 0 ); CREATE TABLE tb_order ( order_id INTEGER PRIMARY KEY, user_id INTEGER, room_id INTEGER, room_no TEXT(20), type_name TEXT(50), in_date DATETIME, out_date DATETIME, book_price MONEY, order_status INTEGER DEFAULT 0, create_time DATETIME ); CREATE TABLE tb_admin ( admin_id INTEGER PRIMARY KEY, admin_name TEXT(50) NOT NULL, admin_pwd TEXT(50) NOT NULL );

注意第一行，user_id 我写成了 INTEGER PRIMARY KEY，在 ACCESS 里这个字段不会自动增长。如果你希望它是自增的，要改成 COUNTER PRIMARY KEY，或者在表设计视图中手动把该字段设为自动编号。COUNTER 是 Jet SQL 里的自增类型，它只能作为主键单独存在，不能参与运算。如果你在建表时用了 INTEGER 又想自动编号，那插入记录时就一定要手动指定 user_id，否则会主键冲突。

日期字段传入时有个细节：ACCESS 默认按系统的区域设置解析日期字符串，比较稳妥的写法是在 ASP 端将日期格式化成 yyyy-mm-dd 再拼进 SQL，避免中文操作系统下把 2025-07-01 当成非法格式。另外，ACCESS 的布尔类型叫 YESNO，存储值是 -1 和 0，我先前提过状态字段用数字更直观，所以建表脚本里订单状态和房间状态都用 INTEGER，写入 0 和 1，查询时一眼就能看懂。

3.3 公共连接文件 conn.asp：连接串里最容易写错的地方

所有页面连数据库，都靠一个公共包含文件，文件名大家默认叫 conn.asp。它的作用是定义连接字符串、创建 Connection 对象、打开数据库，然后让其他 .asp 页面在最顶部用<!--#include file="conn.asp"-->引入。这样数据库路径只要改一处，全站生效，不用每个页面重复写连接逻辑。

<% Dim conn, connstr, dbPath dbPath = Server.MapPath("data/hotel.mdb") connstr = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & dbPath Set conn = Server.CreateObject("ADODB.Connection") conn.Open connstr %>

这段代码里最容易出错的点有三个。第一是 Server.MapPath 的参数，它用的是网站根目录下面的相对路径，如果你的 .mdb 文件放在 data 文件夹里，那括号里就写 "data/hotel.mdb"；不要用绝对路径，换一台机器、换一个站点目录就全乱了。第二是 Provider，Access 2003 及更早格式的 .mdb 文件用 Microsoft.Jet.OLEDB.4.0；如果数据库是 .accdb 格式，要换成 Microsoft.ACE.OLEDB.12.0。第三是数据库文件名的后缀，有的同学建库时存成了 hotel.accdb，连接串还写着 .mdb，这会在打开连接时直接报"未找到提供程序"。

数据库文件放哪个目录也有讲究。我见过放在站点根目录的，结果访问者直接输入完整路径就能把 .mdb 下载走，整个数据库裸奔。正确做法是单独放在一个 data 子目录，并通过 IIS 权限设置禁止该目录的匿名读取，或者干脆放到网站根目录之外的物理路径，连接时用 Server.MapPath 映射到上级目录。这个问题在后面的部署章节还会提，但你在建库时就要把目录规划好，不然最后打包交付时还要挪文件、改路径。

4. ASP 核心代码实现：登录、查询、下单三个关键链路

数据库建好后，写代码的顺序我一般推荐从登录开始。登录链路通了，Session 概念就落地了；再做客房列表和分页，把 Recordset 的用法搞清楚；最后做下单事务，把 Access 的锁机制和事务处理过一遍。这三段代码是整套系统的骨架，其他页面基本都是在这三个基础上加字段。

4.1 注册与登录：表单取值、Session 写入、SQL 注入入口

登录页的表单提交到 login_check.asp，处理逻辑分三步：接收表单字段、查询数据库、根据结果写入 Session 或返回错误。这段代码是所有管理系统的通用模板，你在任何一份项目的登录页面里都能看到类似结构：

<%@ Language="VBScript" CodePage=65001 %> <!--#include file="conn.asp"--> <% Dim userName, userPwd, sql, rs userName = Trim(Request.Form("username")) userPwd = Trim(Request.Form("password")) If userName = "" Or userPwd = "" Then Response.Write "<script>alert('用户名和密码不能为空');history.back();</script>" Response.End End If sql = "SELECT * FROM tb_user WHERE user_name='" & userName & "' AND user_pwd='" & userPwd & "'" Set rs = Server.CreateObject("ADODB.Recordset") rs.Open sql, conn, 1, 1 If Not rs.EOF Then Session("user_id") = rs("user_id") Session("user_name") = rs("user_name") Session("is_login") = True Response.Redirect "index.asp" Else Response.Write "<script>alert('用户名或密码错误');history.back();</script>" End If rs.Close Set rs = Nothing %>

代码的逻辑说明：Request.Form 拿到的是表单 POST 过来的数据，Trim 去掉首尾空格，避免用户输入 "admin " 这种带空格的值导致查询失败。查询用的是 SELECT *，Recordset 以只读方式打开，参数 1 和 1 分别代表游标类型为键集、锁定类型为只读。判断 rs.EOF 是否为空集，不为空说明用户名密码匹配，写入三个 Session 变量后跳转首页；为空则弹窗报错并回退上一页。

这段代码暴露了一个老生常谈的问题：SQL 注入。用户名的输入框里输入' OR '1'='1这种字符串，拼进 SQL 后条件恒真，就能跳过密码校验直接登录。课程设计的论文里，你们多半会写"本系统对用户输入进行了合法性校验"，但实现时往往没做。最简单的防御是在拼接前把单引号替换成两个单引号，Access 里双单引号会被转义成普通单引号：

userName = Replace(userName, "'", "''") userPwd = Replace(userPwd, "'", "''")

这两行代码加在变量赋值之后、拼接 SQL 之前。它是基于字符串转义的防护，不能完全替代参数化查询，但在这个项目规模下是成本最低、最好讲清楚的方案。论文里可以写"系统对用户输入的单引号进行了转义处理，防止 SQL 注入"，这句话是能被验证的。

4.2 客房列表分页：Recordset 自带分页比手写 LIMIT 更适合 Access

Access 的 SQL 不支持 MySQL 的 LIMIT 语法，所以分页要么靠 Recordset 自带的 PageSize 和 AbsolutePage 属性，要么用子查询模拟。前者是 ASP 老司机的标准做法，代码更简洁：

<% Dim rs, sql, pageSize, curPage, totalPages pageSize = 6 curPage = Request.QueryString("page") If Not IsNumeric(curPage) Or curPage = "" Then curPage = 1 curPage = CLng(curPage) sql = "SELECT r.room_id, r.room_no, r.floor_no, r.room_status, t.type_name, t.price FROM tb_room r LEFT JOIN tb_roomtype t ON r.type_id = t.type_id ORDER BY r.room_id" Set rs = Server.CreateObject("ADODB.Recordset") rs.PageSize = pageSize rs.Open sql, conn, 1, 1 If rs.EOF Then Response.Write "暂无客房数据" Else totalPages = rs.PageCount If curPage > totalPages Then curPage = totalPages rs.AbsolutePage = curPage For i = 1 To pageSize If rs.EOF Then Exit For Response.Write rs("room_no") & " | " & rs("type_name") & " | " & rs("price") & "<br>" rs.MoveNext Next End If %>

参数说明：pageSize 是每页显示的记录数，这里设为 6；curPage 从 URL 的 QueryString 获取，用 IsNumeric 判断合法性，防止非数字传参导致类型错误。rs.PageSize 指定每页记录数，rs.Open 执行查询后，rs.PageCount 自动算出总页数。关键行是 rs.AbsolutePage = curPage，它让游标直接跳到目标页的第一条记录，随后循环输出当前页的记录。当最后一页不满 pageSize 时，循环体内判断 rs.EOF 及时跳出。

这种分页方式的优点是不用手动计算偏移量，缺点是每次都把整个结果集查出来然后由游标定位，数据量大了会慢。但酒店管理系统客房通常几十到几百间,性能影响可以忽略。分页链接的生成逻辑就是循环输出页码数字，每个超链接带上?page=N参数，当前页高亮显示，这段代码就不展开了。你只需要记住，在 Access 下不要用 LIMIT，不然报错时你根本想不到是 SQL 方言的问题。

4.3 提交订单：用事务把订单写入与房间状态变更绑定

下单是酒店系统里对数据一致性要求最高的一步。用户提交订单后，要同时完成两件事：往订单表插入一条记录、把对应房间的状态从空闲改为占用。如果第一件事成功、第二件事失败，就会产生订单存在但房间显示空闲的数据不一致。解决这个问题要靠事务：

<% On Error Resume Next Dim aUserId, aRoomId, aInDate, aOutDate, aPrice, aDays aUserId = Session("user_id") aRoomId = CLng(Request.Form("room_id")) aInDate = Request.Form("in_date") aOutDate = Request.Form("out_date") aPrice = CDbl(Request.Form("book_price")) aDays = DateDiff("d", CDate(aInDate), CDate(aOutDate)) conn.BeginTrans conn.Execute "INSERT INTO tb_order(user_id, room_id, room_no, type_name, in_date, out_date, book_price, order_status, create_time) VALUES(" & aUserId & "," & aRoomId & ",'" & aRoomNo & "','" & aTypeName & "','" & aInDate & "','" & aOutDate & "'," & aPrice & ",0,NOW())" conn.Execute "UPDATE tb_room SET room_status=1 WHERE room_id=" & aRoomId If Err.Number = 0 Then conn.CommitTrans Response.Write "<script>alert('预订成功');location.href='myorder.asp';</script>" Else conn.RollbackTrans Response.Write "<script>alert('预订失败，请重试');history.back();</script>" End If %>

事务的逻辑说明：conn.BeginTrans 开启事务，两条 Execute 语句分别做插入和更新。On Error Resume Next 让错误不中断页面执行，而是设置 Err.Number。事务结束后检查 Err.Number，为 0 说明两步都成功，CommitTrans 提交；否则 RollbackTrans 回滚到事务开始前的状态。这样即使更新客房状态的那句 SQL 因为锁库失败，订单插入也会一起撤销，不会留下半截数据。

这段代码在实际运行时会遇到一个问题：Access 在事务期间会锁定涉及的表，如果同时有另一个用户也在下单，可能因为背锁导致连接超时。解决思路是尽量缩短事务内的操作时间，把字段校验、价格计算都放在事务之外完成。还有一点，订单金额和房价差异要提前算好，事务里只做写入不做复杂计算。如果一个页面里有多个事务，建议只保留最关键的那一处，事务是保护数据一致性的工具，不是越多越好。

5. 部署运行与常见问题排查：IIS、64位与Access锁库

代码写完了，真正的考验才刚刚开始。ASP+ACCESS 项目在别的机器上跑不起来，十有八九不是代码问题，而是运行环境问题。这一章专门讲部署步骤和四个高频踩坑点，每条都按现象、原因、解决来写，你遇到时直接对号入座。

5.1 从零部署：打开 IIS 的 ASP 功能与最小权限配置

在 Windows 上部署 ASP 站点，第一步是确认 IIS 已经安装了 ASP 模块。Windows 功能默认不装 ASP，只装了静态网页和 IIS 管理工具，导致访问 .asp 文件时直接报 404 或 500。图形界面操作路径是：控制面板 -> 程序 -> 启用或关闭 Windows 功能 -> Internet Information Services -> 万维网服务 -> 应用程序开发功能，勾选 ASP。这一步做完后，IIS 管理器里选中你的站点，双击"ASP"图标，把"启用父路径"设为 True，因为代码里用了 Server.MapPath 相对路径和 include 上一层目录。

创建网站时，应用程序池要选择"经典"托管管道模式，IIS 默认是"集成"模式，经典 ASP 应用在集成管道下会报 500.23 错误。本机 IIS 版本不同，界面选项略有差异，但这两个位置必须改。权限方面，给存放数据库的 data 文件夹授予 IIS 账户的修改权限，步骤是右键文件夹 -> 属性 -> 安全 -> 编辑 -> 添加 -> 输入 IIS_IUSRS -> 勾选修改。没有写权限的症状是网站能打开、能显示页面，但一执行插入或更新操作就报"不可更新"或"操作必须使用一个可更新的查询"。

5.2 问题一：HTTP 500.23 或 500.19，ASP 功能未启用或管道模式不对

现象：浏览器访问站点首页 .html 正常，访问 login.asp 直接报 HTTP 500.23 或 500.19，错误信息里提到"无法在此配置路径上使用配置"或"ASP 功能未安装"。

原因：两层可能。第一层是 IIS 的 ASP 模块根本没启用，Windows 功能里没勾选；第二层是应用程序池处于"集成"模式，经典 ASP 需要"经典"模式。

解决：先到 Windows 功能里确认 ASP 是否勾选，没勾选就勾上并重启 IIS，命令行执行iisreset。然后再到应用程序池中把对应站点的托管管道模式改为"经典"。改完重启站点，错误消失。这个问题的检查顺序要固定：先查程序池模式，再查 Windows 功能，因为改管道模式比装功能快得多。

5.3 问题二：未找到提供程序（800a0e7a），64位IIS跑32位驱动

现象：页面可以打开，但凡是执行数据库连接或查询的代码，报错Provider cannot be found. It may not be properly installed.，错误码 800a0e7a，中文系统显示"未找到提供程序"。数据库文件确认存在，连接串确认没错。

原因：这是 64 位 Windows 上跑 ASP+ACCESS 的经典问题。Microsoft.Jet.OLEDB.4.0 是一个 32 位驱动，64 位 IIS 进程默认加载不了 32 位的 OLEDB 提供程序。很多同学的开发机是 64 位 Windows，本地跑没问题是因为 Visual Studio 或 Access 装过 32 位组件，换到纯 64 位服务器就翻车。

解决：在 IIS 应用程序池的高级设置中，把"启用 32 位应用程序"设为 True，让 IIS 以 32 位模式运行该站点。路径是应用程序池 -> 高级设置 -> 常规 -> 启用 32 位应用程序 -> True。改完重启站点。如果你的环境不支持开 32 位兼容，另一个方案是改用 Microsoft.ACE.OLEDB.12.0 驱动并安装对应的 Access 数据库引擎红ist，但那个驱动也分 32/64 位版本，选型更麻烦。我一般直接开 32 位兼容，最省事。

5.4 问题三：Access 数据库被锁定，或写入超时

现象：系统刚部署时正常，运行一段时间后开始随机报错，提示Could not update; currently locked by user 'Admin' on machine，或者"因正在使用中而无法锁定数据库"。重启 IIS 后短暂恢复，过一会又出现。

原因：ACCESS 是文件型数据库，写入时会锁定整个 .mdb 文件。多人同时写入、或者有一个页面长时间持着连接没关闭，都会导致锁库。还有一种隐蔽情况：连接对象没有显式关闭，IIS 进程把连接一直攥在手里，文件就被锁死了。

解决：首先要规范代码，所有 Recordset 用完就 Close，Connection 在页面末尾 Set Nothing。这是治本。其次是在业务层规避，下单事务里不要做耗时操作，能提前计算的都提前算好。第三，检查有没有后台页面开着事务但一直没提交，比如管理员在后台编辑页面挂机，事务会自动锁库直到超时。把这些都处理完，锁库频率会大幅下降。ACCESS 的并发能力就这个水平，不要把责任推给代码，接受它。

5.5 问题四：中文乱码与数据库路径 404 或无法下载

现象：页面文字显示正常，但数据库中读取的中文显示成乱码；另一个场景是浏览器直接输入 data/hotel.mdb 的路径，竟然把数据库文件下载了。

原因：乱码是因为 ASP 页面文件的编码和响应输出编码不一致。页面文件保存成了 ANSI 编码，但浏览器强制 UTF-8，或者反过来。数据库文件可下载则是因为 IIS 把 .mdb 当成静态文件直接返回了，说明该目录允许匿名读取。

解决：乱码的规律是"页面文字正常、数据库内容乱"，检查 ASP 文件顶部有没有<%@ Language="VBScript" CodePage=65001 %>，并且保证文件本身以 UTF-8 编码保存。历史项目里很多页面用的是 GB2312，那就统一改成CodePage=936，关键是全站一致，不能一半 65001 一半 936。数据库目录的防护，打开 IIS 管理器，选中 data 文件夹，双击"处理程序映射"，把 .mdb 的静态文件处理禁用；更彻底的做法是把数据库目录放进请求过滤规则中，拒绝所有直接访问。这个坑不踩到，你的数据库可能早就被人拖走了。

6. 让这套代码在答辩现场站得住：验证方法、安全加固与论文呼应技巧

这一章是交付前的收尾动作。项目包里有开题报告和论文，答辩时最容易出现的局面是：系统能跑，但你被问到某个功能"在哪个页面、哪段代码里实现"时，答不上来。我的习惯是答辩前两三天做一张功能点对照表，把论文里写的每一句话映射到具体文件和代码段。

对照表长这样：功能点写"用户注册"，对应文件写 reg.asp 和 reg_check.asp，数据库操作写 INSERT 到 tb_user；功能点写"客房分页展示"，对应文件写 room_list.asp，数据库操作写 SELECT + Recordset 分页；功能点写"管理员确认订单"，对应文件写 admin/order_handle.asp，数据库操作写 UPDATE tb_order SET order_status=1。答辩时被问到这里，直接指着表说"这个功能由这三个文件串联实现"，比现场翻代码快得多。

安全加固只做两件事就够：一是把所有接收用户输入的地方过一遍单引号过滤，这一步能挡住大部分注入；二是后台入口不要暴露在首页，给登录链接换一个不显眼的路由，比如 admin_login.asp，能挡住一半以上的扫描流量。真遇到较真的老师，让他输入一个注入向量，证明你处理过，这就是最好的验收。性能验证不用做压测，ACCESS 的并发瓶颈摆在那，你只需要用浏览器开发者工具看下单页的响应耗时，确认在毫秒级别就行。

论文里的数据流图，直接按照第 2 章的页面流转图改画成三层结构：浏览器请求 -> IIS 解析 ASP -> ADO 操作 ACCESS 数据库。数据流用箭头标清方向，这点东西画明白，整个系统的技术路线就自洽了。我每次交付这类项目，都会先在测试环境跑一遍注入和锁库测试再交出去，因为数据库路径和权限这些事，只有亲手遇过一次才有记性。希望帮到你。

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