简介：这份实验报告面向高校计算机及相关专业学生，聚焦《数据库应用程序开发》课程中Java与DB2交互的实操训练，适合正在学习JDBC编程、需要完成课程实验或复习数据库应用开发基础的学习者参考。资源包共1个doc文档，大小约1.76MB，内容以实验报告形式组织，涵盖JDBC连接建立、Statement与PreparedStatement使用、ResultSet结果集遍历、事务提交控制及SQL异常处理等核心知识点。报告按任务逐项记录调试过程与运行结果，包括权限授予、对象名称修正、salary字段溢出原因分析、GUI改造与约束异常提示等典型问题的排查思路，并配有截图说明。已有902人学习下载，读者可借此对照实验步骤理解数据库与Java程序的交互流程，掌握常见错误的定位与解决方法，为后续数据库应用开发打下基础。

1. 权限报错、未定义名称、事务不生效：JDBC 连 DB2 的三个高频翻车点

跑 JDBC 连 DB2 的实验，最让人抓狂的不是写不出 SQL，而是代码看着全对，一运行就给你甩脸色：要么db2admin没有访问EMPLOYEE的权限，要么命令行一执行就报DB2ADMIN.TEMPL是一个未定义的名称，要么更新语句返回成功、数据库里却纹丝不动。这三类问题几乎覆盖了数据库应用程序开发实验里八成以上的调试时间，新手卡在第一条就动不了，熟手也常被“成功但没生效”这种玄学现象绕进去。这篇笔记按报错现象、根因、可抄作业的解决步骤往下推，适合正在做 JDBC 增删改查、被权限和事务坑住的开发者，也适合想把排查路径固化下来的人。

2. 权限与对象名报错：为什么 db2admin 访问不了 EMPLOYEE

2.1 报“没有访问 EMPLOYEE 的权限”时先查授权链

这类报错通常出现在任务 1 补充程序片段之后，程序能连上库，但一执行查询就抛权限异常。根因不在 JDBC 代码，而在 DB2 的用户授权模型：EMPLOYEE表建在JLU用户模式下，db2admin只是另一个用户，默认没有任何跨模式的表访问权。很多人第一反应是改连接串里的用户名密码，这没用，因为问题出在库内的对象权限，不是登录认证。

常见做法是登录到拥有该表的用户，把访问权显式授出去。命令行里执行：

-- 以 JLU 用户登录后执行，把 EMPLOYEE 的查询权限授予 db2admin CONNECT TO sample USER JLU; GRANT SELECT ON JLU.EMPLOYEE TO USER db2admin; -- 如果程序还要做增删改，按需补上对应权限 GRANT INSERT, UPDATE, DELETE ON JLU.EMPLOYEE TO USER db2admin;

GRANT SELECT只给读权限，实验里如果后续任务要改数据，得把INSERT/UPDATE/DELETE一起授了，否则会在下一个任务里再翻一次车。授权完成后重新用db2admin连接执行，权限异常应当消失。这里的关键认知是：JDBC 的getConnection成功只代表认证通过，不代表你对目标表有操作权，两者是两层校验。

2.2 “DB2ADMIN.TEMPL 是一个未定义的名称”的两种来源

这个报错在任务 1 和任务 5 都出现过，但根因不完全一样，得分开看。任务 1 里，代码中写的是TEMPL，而实际对象在JLU模式下，DB2 在解析未加模式前缀的表名时，会默认补上当前连接用户的模式，于是拼成了DB2ADMIN.TEMPL，自然找不到。解决办法是把代码里的表名改成带模式的全名JLU.TEMPL，让解析不再依赖默认模式。

任务 5 更隐蔽：想创建JLU.TEMPL表却创建不了，报的是对象已存在或名称冲突。根因是之前给EMPLOYEE建过别名TEMPL，别名和表在同一个命名空间里抢名字。处理方式是先删掉旧别名再建表：

-- 先确认当前模式下有哪些别名和表在抢 TEMPL 这个名字 SELECT NAME, TYPE FROM SYSIBM.SYSTABLES WHERE NAME = 'TEMPL'; -- 删除遗留别名后再创建表 DROP ALIAS JLU.TEMPL; CREATE TABLE JLU.TEMPL ( ... );

SYSIBM.SYSTABLES里TYPE字段能区分是表还是别名，先查再删，避免误删真实表。这类“名称未定义”看着像代码 bug，实际是模式解析和命名空间冲突，排查顺序应该是：先确认对象真实全名，再确认当前连接用户的默认模式，最后才怀疑代码拼写。

3. 更新成功却不生效：事务提交与溢出报错怎么定位

3.1 setAutoCommit(false) 之后忘了 commit 的典型症状

任务 3 里最迷惑的现象是：输入 20 或 30，程序执行成功，executeUpdate也返回了影响行数，但去 DB2 里查，数据一点没变。很多人会怀疑 SQL 写错、怀疑表被锁，甚至在 DB2 命令行里手动改一遍验证“库本身能改”，结果证明库没问题，问题在 Java 程序。根因就是sample.setAutoCommit(false)把自动提交关了，后续所有更新都挂在一个未提交的事务里，连接一关就回滚了。

解决方式有两种，按实验要求选。如果就是要练手动事务，那必须在更新后显式提交：

// 关闭自动提交，手动控制事务边界 sample.setAutoCommit(false); try { int updateCount = pstmt.executeUpdate(); sample.commit(); // 关键：不 commit 数据不会落库 System.out.println("影响行数: " + updateCount); } catch (SQLException x) { sample.rollback(); // 出错回滚，避免半截事务 System.out.println("SQLCode=" + x.getErrorCode() + " SQLState=" + x.getSQLState() + " Message=" + x.getMessage()); }

commit()是让改动真正写进库的动作，rollback()是出错时的后悔药。如果实验不要求手动事务，直接把setAutoCommit(false)改成true也能让更新立即生效，但这样就失去了事务控制的练习意义。我一般会保留false并补上commit，因为真实业务里批量更新几乎都要手动控制边界。

3.2 类型转换溢出：为什么输入 15 和 20 会炸、16 却“改 0 行”

溢出报错的表现是类型转换时数值超出字段范围。实验里通过改 SQL 因子做了对照：salary*2时 15 和 20 都溢出，salary*1.01时都不溢出，这就把根因锁定在“修改后的数值超过了salary字段能容纳的范围”，而不是代码类型声明写错。定位手法很直接：先用 DB2 查出相关行的原始salary，手算放大后的值，再对照字段定义看上限。

-- 查字段类型和精度，确认能装多大 SELECT COLNAME, TYPENAME, LENGTH, SCALE FROM SYSIBM.SYSCOLUMNS WHERE TBNAME = 'STAFF' AND COLNAME = 'SALARY'; -- 查目标行的原始值，手算放大结果 SELECT ID, NAME, SALARY FROM JLU.STAFF WHERE DEPT = 20;

LENGTH和SCALE决定了数值上限，放大后的值一旦越界就会在executeUpdate时抛溢出。另一个容易混淆的点是“输入 16 反馈修改了 0 行”：这不是溢出，是数据库里根本没有对应记录，executeUpdate返回 0 是正常语义。把“返回 0 行”和“抛溢出异常”分开看，能少走很多弯路。

4. GUI 改造与异常处理：JOptionPane 和约束报错怎么接住

4.1 用 JOptionPane 做输入输出时的空值与类型坑

任务 4 要求把labupdate.java改成 GUI 形式，输入和结果都走JOptionPane。这里最常见的翻车是JOptionPane.showInputDialog返回的是字符串，直接拿去setInt会抛类型不匹配；用户点取消返回null，不判空就parseInt会直接空指针。稳妥写法是先判空再转换，转换失败给提示而不是让异常冒到控制台：

String input = JOptionPane.showInputDialog("请输入部门号:"); if (input == null || input.trim().isEmpty()) { JOptionPane.showMessageDialog(null, "输入不能为空"); return; } int mydeptno; try { mydeptno = Integer.parseInt(input.trim()); } catch (NumberFormatException e) { JOptionPane.showMessageDialog(null, "请输入合法数字"); return; } pstmt.setInt(1, mydeptno);

trim()是为了挡掉用户手滑打出的空格，NumberFormatException捕获的是非数字输入。GUI 改造本身不难，难在把控制台时代的“报错看堆栈”换成“报错弹对话框”，所有用户输入路径都得当成不可信数据处理。

4.2 任务 7 的异常分类：约束、类型、溢出、非法符号各归各的

任务 7 要求用对话框提示所有操纵类错误，实验里列了四类：违反约束、类型不匹配、溢出、SQL 语句非法符号。这四类在SQLException里靠getErrorCode()和getSQLState()区分，统一 catch 之后按错误码分流提示，比每个操作各写一套 try-catch 更好维护：

try { int n = pstmt.executeUpdate(); JOptionPane.showMessageDialog(null, "影响行数: " + n); } catch (SQLException x) { String msg; switch (x.getErrorCode()) { case -803: msg = "违反唯一约束"; break; // 具体码以实际库为准 case -545: msg = "数值超出字段范围"; break; default: msg = "SQLState=" + x.getSQLState() + " 信息=" + x.getMessage(); } JOptionPane.showMessageDialog(null, msg); }

错误码的具体数值要以实际 DB2 版本返回为准，实验里更稳的做法是先把getErrorCode、getSQLState、getMessage三个值原样弹出来，跑一遍四类错误各记一次，再回头写分流逻辑。这样既完成了异常处理要求，也顺手把错误码对照表建起来了。

5. 避坑清单：五个反复踩到的 JDBC 实验坑

5.1 坑一：连接成功就以为有表权限

现象是程序连库正常，一查表就报权限异常。原因是认证和对象授权是两层，db2admin登录成功不代表对JLU模式下的表有访问权。解决是按 2.1 的GRANT语句补授权，并且把后续任务需要的增删改权限一次授全，别等下一个任务再回来补。

5.2 坑二：表名不带模式前缀

现象是报DB2ADMIN.XXX 未定义。原因是未加前缀的表名会被补上当前用户模式，和实际对象所在模式对不上。解决是代码里统一写全名JLU.表名，或者在连接后执行SET SCHEMA JLU把默认模式切过去，二选一，别混着用。

5.3 坑三：别名和表抢名字

现象是建表失败，提示名称冲突。原因是之前给别的表建过同名别名，别名和表共享命名空间。解决是先查SYSIBM.SYSTABLES确认TYPE，删掉遗留别名再建表，删之前务必确认不是真实表。

5.4 坑四：关了自动提交不 commit

现象是更新返回成功但库里没变。原因是setAutoCommit(false)后事务未提交，连接关闭即回滚。解决是补commit()，出错走rollback()，别只改true了事，那样事务练习就白做了。

5.5 坑五：把“改 0 行”当成溢出

现象是输入某个部门号后提示修改 0 行，误以为是数值问题。原因是该部门在表里没有记录，executeUpdate返回 0 是正常结果。解决是先SELECT确认记录存在，再区分“0 行”和“抛溢出异常”两种完全不同的反馈。

6. 快速定位这类问题的排查顺序与验证手法

被 JDBC 报错卡住时，我一般按“连接层 → 对象层 → 语句层 → 事务层”四步往下压，每步都有明确的验证动作，不靠猜。连接层先确认getConnection用的 URL、用户、密码和实际库一致，能连上就进下一步；对象层用SYSIBM.SYSTABLES和SYSIBM.SYSCOLUMNS查对象真实全名、类型和字段精度，把“名称未定义”和“溢出上限”这两类问题在这一层摁掉；语句层把拼好的 SQL 拿到 DB2 命令行里裸跑一遍，能跑通说明问题在 Java 参数绑定，跑不通说明 SQL 本身有问题；事务层最后查getAutoCommit状态和有没有commit，专治“成功但不生效”。

验证手法上，我习惯在 catch 里把getErrorCode、getSQLState、getMessage三个值一次性打全或弹全，别只打一句“出错了”。这三个值分别对应库内错误码、标准状态码和人类可读信息，定位时缺一个都可能多绕半小时。GUI 任务里也一样，异常对话框先把原始三值展示出来，再谈友好提示，顺序反了就会把根因藏起来。

从那以后我每次写 JDBC 更新逻辑，都强制走一遍“先 SELECT 验证记录、再确认 autoCommit、最后 commit 并回查”的固定动作，权限和模式前缀也在建连接后第一时间确认，不再等报错来提醒。希望这套顺序能帮到你，少在同一个坑里翻两次车。

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