Java课程设计实战：SQL Server数据库还原与老项目部署全攻略

简介：一套基于Java开发的月亮湾酒店管理系统完整源码，配套SQL Server数据库脚本，面向正在学习Java桌面应用开发、需要课程设计或毕业设计参考的高校学生与初级开发者。系统涵盖团队预订、个人预订、查询、入住登记等功能模块，代码结构清晰，便于理解业务逻辑与界面交互的实现方式。压缩包内含350个文件，56个java源文件与60个class文件构成核心代码，176个gif图片用于界面展示，另有5个doc格式设计文档（概要设计、数据库设计、需求说明、详细设计、用户手册）及SQL Server数据库脚本，可帮助读者掌握从需求分析到代码落地的完整开发流程。资源包大小约9.74MB，已有101人学习浏览，适合需要借鉴完整Java管理系统项目经验的学习者参考使用。

1. 月亮湾酒店管理系统是什么：一套Java+SQL Server数据库的完整课程设计

「月亮湾酒店管理系统」这个标题，放在Java课程设计案例源码里很典型：一个基于JSP/Servlet的Web工程，配一份SQL Server数据库备份，压缩包解压后就能看到传统的src、WebRoot、lib三层结构。它不是让你读代码的，是让你把整条链路跑通——数据库还原、JDBC连接、Tomcat部署，全流程走一遍，正好对应学完Java基础后想找项目练手的人。实际动手你会发现，真正卡住你半天的不在Java代码，而在SQL Server这边：登录模式、端口、备份还原方式，哪一步没对齐都连不上。这篇就按我实操的顺序讲：先认清技术栈，再把数据库弄活，最后部署验收、避开那些反复出现的坑。

2. 先认清这套Java酒店管理系统的技术栈：不只JDK，还有SQL Server数据库版本

拿到压缩包，别急着双击启动脚本。先解压看目录，判断它属于哪个时代的Java Web项目，再决定装什么JDK、什么Tomcat、什么SQL Server。这一步决定了后面几个小时是顺利还是反复翻车。

2.1 解压后先看目录：判断这是Spring Boot还是老式Servlet项目

一个典型的课程设计压缩包，根目录下通常是这几样：src（Java源码）、WebRoot（或web），里面是JSP、WEB-INF、lib等一套，外加一个数据库相关文件。它没有pom.xml，也没有application.yml，说明不是Maven管理、不是Spring Boot那一套，而是最传统的Servlet + JSP + JDBC工程。

判断依据其实就两个。第一，有没有pom.xml：有就是后期改造成Maven结构，没有就是原生Java Web。第二，WEB-INF/lib下是一堆.jar手写依赖，还是空的：老项目习惯把sqljdbc4.jar、jstl.jar这些直接塞进lib。如果代码里能找到Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver")，那就更确定了——这是教科书时代的写法，先加载驱动再拿连接。

为什么课程设计案例源码喜欢这种结构？因为简单直接，不依赖Maven中央仓库，离线也能编译，老教材默认这么教。你后面做的事不是重构它，而是按它的规矩把它跑起来。这套月亮湾酒店管理系统大概率也是这个路数，所以后面的环境配置都要按老项目来，而不是拿Spring Boot那套思维硬套。

2.2 JDK和Tomcat版本：老项目跑在新环境上最容易翻车

老项目的编译目标通常是Java 1.7或1.8。你现在机器上如果装的是JDK 11、JDK 17，直接打开源码编译，轻则警告，重则直接报UnsupportedClassVersionError，这是最典型的JAVA环境配置问题，而且报错信息不会告诉你“版本不对”，只会给你一个class文件版本号。

我一般会先执行java -version确认当前JDK，再决定要不要换成JDK 8。

java -version

如果显示的是openjdk version "17"这类，那大概率要换回JDK 8。老项目对JDK 8最友好，主要原因是Java 9之后模块化拆分了javax包，11之后又有jakarta namespace迁移，老代码里的import javax.servlet.*在新Tomcat上可能直接编译不过。

版本对照关系大概是这样的：

Tomcat建议用8.5.x，配JDK 8，兼容性好，Servlet 3.1规范也够老项目用。如果你手头是Tomcat 10，那是给Servlet 5.0/Jakarta EE用的，老代码里的javax.servlet全部要改成jakarta.servlet，课程设计项目不值得为它做迁移，直接换Tomcat 8.5更快。

2.3 SQL Server 2008 R2到2019：数据库版本怎么选

SQL Server这边的坑比JDK还多。早期课程设计搭的环境大多是SQL Server 2008 R2或2012，你装个SQL Server 2019也能用，但还原旧备份时会出现兼容性级别问题。

SQL Server 2008 R2的数据库兼容性级别是100，2012是110，2019是150。旧库挂到新实例后，兼容性级别不会自动升级，某些老语法可能还能跑，但如果你用新版SSMS去改表结构，偶尔会提示不兼容。我的建议是：能装SQL Server 2012就用2012，装不上就2008 R2，这两个版本和这类老系统是同时代产物。如果机器只允许2019，那还原后手动确认一下兼容性级别。

SELECT name, compatibility_level FROM sys.databases WHERE name = 'MoonBayHotel'; ALTER DATABASE MoonBayHotel SET COMPATIBILITY_LEVEL = 110;

第一句查当前的兼容性级别，第二句把它改成110（对应2012）。这里要注意，COMPATIBILITY_LEVEL = 100对应2008 R2，是这类老项目最常配的级别。安装SQL Server时记得选“混合登录模式”，不然后面用sa连不上，这是数据库安装最容易忽略的选项。

3. 把SQL Server数据库先跑起来：从备份还原到JDBC能连通

数据库是这套系统的地基，地基没起来，Java代码再对也没用。这一章说清楚三种常见的数据库文件形态，以及每一步怎么验证。

3.1 判断rar里带的是.bak还是.sql：两种恢复方式的坑

压缩包里写“含数据库”，实际打开后有三种可能：.bak备份文件、.sql脚本文件、.mdf/.ldf物理文件。它们各自恢复方式完全不一样。

如果是.bak，用SSMS还原或T-SQL的RESTORE都行。我习惯用RESTORE命令，因为能看到逻辑名和路径，出错信息更明确：

RESTORE DATABASE MoonBayHotel FROM DISK = N'C:\db\moonbay.bak' WITH REPLACE, MOVE N'MoonBay_Data' TO N'C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA\MoonBayHotel.mdf', MOVE N'MoonBay_Log' TO N'C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA\MoonBayHotel_log.ldf';

这里最坑的是MOVE后面的逻辑名，必须和备份文件里的实际逻辑名一致，否则还原到一半报错。正确做法是先查询备份里的逻辑名：

RESTORE FILELISTONLY FROM DISK = N'C:\db\moonbay.bak';

这条命令会把备份内包含的所有逻辑文件名列出来，再把它们填到前面那条RESTORE语句里去。如果你懒，可以先不管MOVE，让SQL Server默认还原路径去处理，报错再回来查逻辑名也来得及。WITH REPLACE的意思是允许覆盖现有同名数据库，课程设计场景直接加，省得重复确认。

如果是.sql脚本，那就更简单，打开SSMS选中master库执行，或者用命令行：

sqlcmd -S . -U sa -P 你的密码 -i C:\db\moonbay.sql

但.sql脚本有个问题：它可能只含建库建表语句，不含数据。如果还原完发现房态表是空的，那就是脚本里只有结构没有insert，需要回头找有没有单独的data.sql。

3.2 开启混合登录模式并设置sa密码：用SSMS或Navicat都行

老代码里的db.properties大多写死jdbc.username=sa，这意味着你本地SQL Server必须允许sa账号登录。如果不小心在安装时选了Windows身份验证模式，后面Java代码永远连不上。

用SSMS最快，右键实例选属性，安全性里勾“SQL Server和Windows身份验证模式”，然后展开“安全性 -> 登录名 -> sa”，右键属性设置密码，状态里启用。如果你用Navicat for SQL Server，操作路径类似，它也能改实例属性和登录名。

用T-SQL也可以，适合喜欢命令行的人：

ALTER LOGIN sa WITH PASSWORD = N'StrongPass123', CHECK_POLICY = OFF; ALTER LOGIN sa ENABLE;

CHECK_POLICY = OFF很关键，否则密码必须满足Windows复杂策略，你设个123456会被拒绝。课程设计代码里密码通常就是简单的，这一句能省掉不少事。改完sa后，最好重启一次SQL Server服务，让配置生效。

3.3 JDBC连接串与驱动：先让Java代码连上数据库

数据库和账号都就绪后，先别启动整个Tomcat，先用一个最小Java程序验证JDBC能通。这一步能把问题隔离在“数据库配置”层面，而不是和JSP编译错误混在一起。

找到项目里的db.properties，常见配置长这样：

jdbc.driver=com.microsoft.sqlserver.jdbc.SQLServerDriver jdbc.url=jdbc:sqlserver://localhost:1433;databaseName=MoonBayHotel;characterEncoding=UTF-8 jdbc.username=sa jdbc.password=123456

注意URL里的databaseName必须和还原出来的数据库名一致，大小写不敏感但别写错。1433是SQL Server默认端口，如果你安装时改了端口，这里也要同步改。characterEncoding=UTF-8这个参数加不加在SQL Server驱动上其实影响有限，真正的编码控制在JVM启动参数和JSP声明里，但写上不亏，至少少一个怀疑方向。

对应的Java测试代码：

Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver"); Connection conn = DriverManager.getConnection( "jdbc:sqlserver://localhost:1433;databaseName=MoonBayHotel", "sa", "123456"); System.out.println(conn.isClosed() ? "连接失败" : "连接成功"); conn.close();

这段代码用Class.forName加载驱动，然后通过DriverManager建立连接。如果打印“连接成功”，说明驱动、端口、账号、库名全对，可以放心往下走。如果报com.microsoft.sqlserver.jdbc.SQLServerException，注意看异常信息里的端口号和主机名，八成是SQL Server的TCP/IP协议没开，或者密码策略把sa锁了。

还要检查lib下有没有sqljdbc4.jar或sqljdbc41.jar，这是微软官方JDBC驱动。没有它，上面三行代码第一行就直接ClassNotFoundException。老项目包里的驱动多半是给Java 6/7用的，JDK 8下也能跑，不用特意换新版。

4. Java工程导入与Tomcat部署：从源码目录到登录页能访问

数据库通了，下一步才是把Java工程导入IDE，部署到Tomcat。很多人在这一步反复折腾，问题主要出在IDE不认老项目结构，或者Tomcat的Context路径配不对。

4.1 IDEA导入老式Eclipse Web工程：不要让IDE替你猜结构

老项目大多是Eclipse的工程格式：有.project文件和.classpath，WebRoot目录放页面。用IDEA导入时，不要用Open直接打开，要用File -> New -> Project from Existing Sources，然后选Eclipse项目类型，让IDEA按Eclipse结构解析。

导入后还要手动确认三件事。第一，Project Structure -> Modules里要把src标记为Sources根目录，不然Java文件里的包路径解析不对。第二，WebRoot标记为Web资源目录，否则JSP和静态文件不被打包。第三，把WEB-INF/lib整个目录加入Libraries，否则import了JDBC和Servlet的代码全部飘红。

这三项里最容易漏的是第二项，IDEA常常把WebRoot识别成普通目录，结果编译不报错，但启动后访问登录页永远404。判断标准很简单：Project Structure -> Facets里如果能找到Web，且Web Resource Directory指向WebRoot，那结构就对了。

4.2 把项目挂到Tomcat：Artifact与Context路径

老项目部署有两种方式：一种是IDEA里配置Tomcat，把项目作为Artifact扔进去；另一种是直接改Tomcat的配置文件，用Context指向WebRoot。IDEA方式配置简单，但新手容易把Deployment里的Application Context搞错，导致启动后访问地址不对。

我一般图省事，直接用Tomcat的conf/Catalina/localhost目录，新建一个moonbay.xml，内容如下：

<Context path="/moonbay" docBase="E:\workspace\MoonBayHotel\WebRoot" reloadable="true"/>

path是浏览器访问的根路径，docBase是WebRoot的实际磁盘路径。配置后启动Tomcat，访问http://localhost:8080/moonbay/index.jsp就能看到登录页。reloadable="true"的意思是改了Java类文件自动重新加载，调试阶段有用，但部署验收时建议改成false，防止JSP热加载出怪异问题。

这个方式的好处是绕过IDE的部署逻辑，很直接。坏处是如果你后面要用IDEA调试断点，还得在IDEA里再配一份Tomcat Runtime，把Deployment里的Artifact设置为当前Module。两条路选一条就行，别混用，否则Tomcat启动时一个端口挨两个应用闹鬼。

4.3 启动时依赖缺失：servlet-api和sqljdbc4的收录边界

老项目lib里的jar是满的，但有个边界一定要搞清楚：servlet-api.jar和jsp-api.jar这类Tomcat自己带的jar，不要放进应用的WEB-INF/lib。原因很简单，Tomcat容器启动时会自己加载一份，应用lib里再放一份，两个类加载器都加载了同名类，运行时会出现诡异的ClassCastException，报错内容还在胡说八道。

正确做法是：lib里只留sqljdbc4.jar、jstl.jar这种业务依赖；servlet-api和jsp-api删掉，让Tomcat提供。如果你不确定某个jar到底是谁家的，看报错就好——如果异常里有ClassCastException且堆栈指向Servlet相关类，先把lib里的servlet-api删了重启，八成能好。

双击Tomcat的startup.bat启动后，观察logs/catalina.out和本地打印的日志。看到类似INFO: Deployment of web application archive ... has finished in X ms，说明部署成功。如果看到SEVERE: Exception starting filter，那就是web.xml里配的类找不到，回头查lib依赖。

5. 常见问题排查：连接超时、日期转换失败、Writelog日志暴涨与乱码

跑通一套老系统总会遇到几个反复出现的坑。以下按我实际处理这类项目的频率排序，每条写清楚现象、原因和解决方式。

5.1 连接超时与登录失败：先查SQL Server的网络配置

现象：Java测试类报The TCP/IP connection to the host localhost, port 1433 has failed，或者直接Connection timed out。

原因：SQL Server默认不启用TCP/IP协议，或者安装时选了“仅Windows身份验证”导致sa不可用。还有一种情况是SQL Server Browser服务没启动，命名实例连不上。

解决：打开SQL Server Configuration Manager，找到“SQL Server网络配置”，把“TCP/IP”协议状态改为“已启用”，然后重启SQL Server服务。命令行验证端口是否在监听：

netstat -ano | findstr 1433

如果看到LISTENING，说明端口正常。如果没有，八成是协议没启用，或者实例名带了命名实例后缀，连接串里主机名要写localhost\实例名，比如jdbc:sqlserver://localhost\SQLEXPRESS;databaseName=MoonBayHotel。

5.2 conversion failed when converting date and/or time：日期格式不是你看到的样子

现象：执行SQL或Java代码时报Conversion failed when converting date and/or time from character string。

原因：老系统里的日期字段有的是varchar，有的是datetime/smalldatetime。代码把字符串2018-5-1 12:00直接拼进SQL，SQL Server按当前语言设置解析，一旦遇到2018-5-1 12:33:12这种格式就翻车。常见的错误是SQL Server语言环境是英文，字符串里带中文月份或者格式不是yyyy-MM-dd HH:mm:ss。

解决：在Java层用PreparedStatement的setTimestamp或setDate，不要自己拼字符串。如果临时排查问题，先用CONVERT把字符串明确转成datetime：

java.sql.Timestamp ts = java.sql.Timestamp.valueOf("2025-06-01 14:30:00"); pstmt.setTimestamp(1, ts);

这样驱动会按JDBC标准格式传给SQL Server，绕开字符串解析。排查时不要相信SSMS里看到的时间格式，SQL Server实际存储的二进制和显示给你看的字符串是两回事。

5.3 Writelog等待时间高、LDF文件暴涨：事务日志的两种救法

现象：数据库操作越来越慢，sys.dm_exec_requests里等待类型是WRITELOG，数据目录下的LDF文件涨到十几个GB。

原因：数据库恢复模式是FULL，而课程设计项目根本不做日志备份，事务日志无限增长，所有写操作都要先写日志，日志一大整条链路都变慢。

解决：对这类练手项目，直接把恢复模式改成简单，然后收缩日志文件：

ALTER DATABASE MoonBayHotel SET RECOVERY SIMPLE; GO DBCC SHRINKFILE (MoonBayHotel_log, 1);

注意MoonBayHotel_log是逻辑日志文件名，不是物理文件名。如果报错，先执行DBCC SHRINKFILE(MoonBayHotel_log, 100)或者去SSMS里看“当前数据库 -> 属性 -> 文件”里的逻辑名。RECOVERY SIMPLE表示系统自动截断日志，LDF不会无限膨胀。这条命令只建议在开发或课程设计环境用，生产库改简单恢复模式会丢点恢复能力，别照搬到线上。

5.4 页面中文乱码：三处编码保持一致

现象：JSP页面显示中文全是问号，或者提交表单后数据库里的中文变成乱码。

原因：三层编码不一致。第一层JSP文件本身的编码，第二层JSP编译时的响应编码，第三层数据库排序规则。

解决：按三步逐一检查。JSP页面第一行确定是：

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" %>

同时检查web.xml里有没有配字符编码过滤器。数据库方面，查询当前排序规则：

SELECT DATABASEPROPERTYEX('MoonBayHotel', 'Collation');

如果是SQL_Latin1_General_CP1_CI_AS，而页面是UTF-8，中文就会变成乱码。一劳永逸的做法是在还原后给对应字段改成Chinese_PRC_CI_AS，或者重建数据库时直接选这个排序规则。实际遇到乱码，三种编码都检查一遍，别只盯数据库，JSP的pageEncoding写错是最高频原因。

5.5 启动后404：多数是部署路径没对上

现象：Tomcat正常启动了，但访问http://localhost:8080/项目名/返回404，日志里也没有明显的Error。

原因：部署到Tomcat的Context路径和实际访问路径不一致。IDEA部署时Application Context默认是/项目名_war_exploded，和你想象的不一样；或者直接改了server.xml里Host的appBase，WebRoot没放在正确位置。

解决：用第4章说的moonbay.xml方式部署，path属性就是访问根路径。访问时严格按http://localhost:8080/moonbay/index.jsp来。如果还是404，去看logs/catalina.<date>.log里有没有Deployment of web application directory ... has finished字样，没这行说明Context没加载，多半是docBase路径写错或目录结构不对。

6. 用一条SQL验证房态与订单闭环：老项目就该这么验收

系统能登录只是开始，验证业务闭环才能确认整个数据库和代码是配套的。酒店管理系统的核心流程是入住和退房，我习惯直接写一条带事务的SQL来验证订单表和房态表是否能联动。以下假设订单表是tb_orders、房态表是tb_rooms，实际以你还原出来的表名为准。

BEGIN TRANSACTION; INSERT INTO tb_orders(room_id, guest_name, check_in_date, order_state) VALUES (101, N'张先生', '2025-06-01 14:30:00', N'已入住'); UPDATE tb_rooms SET room_state = N'Occupied' WHERE room_id = 101; COMMIT;

这里用了N'张先生'写中文，是因为SQL Server里的字符串常量前缀N表示UNICODE，避免和排序规则打架。整个事务保证“插入订单”和“更新房态”要么同时成功、要么同时回滚，这才符合酒店管理的基本逻辑。执行后，再分别查两张表：

SELECT * FROM tb_orders WHERE guest_name = N'张先生'; SELECT * FROM tb_rooms WHERE room_id = 101;

如果订单有记录且房态变了，说明数据库层面闭环成立；如果只有订单没有房态更新，那说明这套源码的Service层可能缺少事务控制，后续自己改代码时重点看这里。

验证完数据库，再看Java层的Service和DAO是否也维持了这个闭环。老项目喜欢把事务写在Service方法里，手动conn.setAutoCommit(false)，如果你改代码时用了Spring，注意别把事务注解放错层级。这套系统跑通后，值得改的方向有两个：一是把JDBC直连换成MyBatis或Spring Data JPA，二是补上和房态统计相关的SQL报表，这两个方向都比重新造一个系统更有学习价值。

我第一次跑这类老SQL Server项目时，浪费了半天在JDK版本和TCP/IP协议上，后来学乖了，每次都先花十分钟确认环境版本再解压源码。先看压缩包目录，再定数据库版本，再写JDBC测试，最后才启动Tomcat——这个顺序能帮你把未知问题控制在最小范围。希望帮到你。

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