简介：这份资源是吉林大学《数据库应用程序开发》课程的实验报告，面向正在学习Java与DB2数据库交互的高校学生及自学者，帮助其掌握JDBC编程的核心流程与常见问题排查方法。报告围绕JDBC连接建立、Statement与PreparedStatement使用、ResultSet结果集遍历、事务提交控制及SQL异常处理等知识点展开，并记录了权限授予、对象名称不匹配、数值溢出、事务未提交导致修改失效等典型调试过程，配有运行结果截图与解决思路。资源包共1个doc文档，约1.76MB，内容按任务分节组织，便于对照实验步骤逐项复盘。目前已有902人学习下载，适合需要完成同类数据库实验、理解Java访问DB2完整链路或查漏补缺的读者参考借鉴。

1. 权限报错与未定义名称：JDBC 连 DB2 最先撞上的两堵墙

刚接手 JDBC 连 DB2 的活儿，最容易在第一步就卡住：代码看着没问题，一跑就抛DB2ADMIN.TEMPL is an undefined name，或者干脆提示当前用户没有访问EMPLOYEE表的权限。这类报错在数据库应用程序开发里高频得离谱，尤其做实验、跑课程项目时，环境是别人配好的，schema 和用户权限早就埋好了雷。这篇排错笔记面向正被具体报错卡住的开发者——新手能照着命令把连接跑通，熟手能看清权限模型、schema 限定和事务提交这几层根因。下面按故障场景一层层拆，每个报错都落到能抄的命令和配置上。

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

2.1 报错现象与触发条件

典型现象是程序执行到查询或更新语句时抛异常，消息里带SQLCODE=-551（权限不足）或SQLCODE=-204（对象未定义）。触发条件往往很固定：连接串里用的是db2admin这个管理账号，而目标表EMPLOYEE建在另一个用户（比如JLU）的 schema 下。DB2 的权限是按用户和 schema 双重绑定的，db2admin即便有实例级管理权，也不自动拥有别的 schema 下表的 SELECT/INSERT 权限。另一类报错是代码里写TEMPL，实际对象叫JLU.TEMPL，DB2 在当前 schema 下找不到，直接报未定义名称。

2.2 用 GRANT 把访问权限补上

先确认表到底在哪个 schema 下，再授权。常见做法是登录对象所属用户，执行授权语句：

-- 以 JLU 用户登录后执行，把 EMPLOYEE 的查询和更新权限授予 db2admin GRANT SELECT, INSERT, UPDATE, DELETE ON JLU.EMPLOYEE TO USER db2admin; -- 如果程序还要建表或改结构，补上更宽的权限（按需，不要无脑给） GRANT ALL ON JLU.EMPLOYEE TO USER db2admin;

GRANT后面跟的是权限类型，ON后面必须是schema.表名全限定形式，TO USER指定被授权账号。授权完不需要重启实例，但已建立的连接要重连才生效。我一般会顺手用db2 describe table JLU.EMPLOYEE确认对象存在，避免授权语句本身报对象不存在。

2.3 代码里统一用全限定名

权限补上后，第二堵墙是名称解析。把代码里裸写的TEMPL改成JLU.TEMPL，让 DB2 不依赖当前 schema 去猜：

// 错误写法：依赖当前 schema，换用户就找不到 String sql = "select NAME, JOB, SALARY from TEMPL where ID = ?"; // 正确写法：schema 全限定，谁连都能定位 String sql = "select NAME, JOB, SALARY from JLU.TEMPL where ID = ?";

参数说明：JLU是对象所属 schema，TEMPL是表名，两者用点连接。如果项目里 schema 会变，别硬编码，抽成配置项或从连接属性里读。这一步看着琐碎，但实验里一半的“未定义名称”都是漏了 schema 前缀。

3. 更新不生效与数值溢出：setAutoCommit 和字段精度的坑

3.1 执行成功但数据库没变

现象很迷惑：executeUpdate()返回了正数，程序也不报错，可回数据库一查，salary纹丝不动。根因是连接上执行了sample.setAutoCommit(false)，把自动提交关了，后续的executeUpdate()只是挂在事务里，没有commit()就永远不落盘。实验里输入 20 或 30 时“成功修改但没生效”，就是这一条。

Connection sample = DriverManager.getConnection("jdbc:db2:sample", "db2admin", "db2admin"); sample.setAutoCommit(false); // 手动事务开始 try { PreparedStatement pstmt = sample.prepareStatement( "update JLU.staff set salary = salary * ? where dept = ?"); pstmt.setDouble(1, 1.01); pstmt.setInt(2, mydeptno); int updateCount = pstmt.executeUpdate(); sample.commit(); // 关键：不 commit 前面全白干 } catch (SQLException x) { sample.rollback(); // 出错回滚，避免半截事务 System.out.println("SQLCode=" + x.getErrorCode() + " SQLState=" + x.getSQLState() + " Message=" + x.getMessage()); }

setAutoCommit(false)之后，commit()和rollback()必须成对出现，否则连接归还时事务状态不确定。getErrorCode()拿的是 DB2 的 SQLCODE，getSQLState()是标准五字符状态码，两个一起打出来定位最快。

3.2 类型转换溢出：salary 放大后装不下

输入 15、20 时抛类型转换溢出，怀疑是放大后的数值超出字段精度。验证方法很直接：把salary * 2换成salary * 1.01，如果两个输入都不溢出了，就证明是数值太大而非逻辑错。DB2 的DECIMAL字段有固定精度和小数位，放大倍数一大就超范围。

-- 先查字段定义，确认精度和小数位 SELECT COLNAME, TYPENAME, LENGTH, SCALE FROM SYSCAT.COLUMNS WHERE TABSCHEMA = 'JLU' AND TABNAME = 'STAFF' AND COLNAME = 'SALARY';

LENGTH是总位数，SCALE是小数位，两者决定能存的最大值。改法有两条：要么在 Java 侧先算好再判断是否越界，要么把字段精度调大（ALTER TABLE ... ALTER COLUMN salary SET DATA TYPE DECIMAL(12,2)）。我一般倾向在应用层做范围校验，改表结构影响面太大。

3.3 更新 0 行不是 bug

输入 16 时反馈“修改了 0 行”，别急着怀疑程序。executeUpdate()返回 0 表示where条件没匹配到任何记录，去 DB2 里select * from JLU.staff where dept = 16一查就明白——库里根本没这个部门。这类“假故障”在联调时特别耗时间，养成先查数据再查代码的习惯。

4. 建表冲突与 GUI 插入：别名占位和空值显示

4.1 无法创建 TEMPL 表：别名先占了名字

建表时报对象已存在，但list tables里又找不到同名表，多半是之前给EMPLOYEE建过别名TEMPL。DB2 里别名和表共享命名空间，别名占着名字，表就建不出来。解决是先删别名再建表：

-- 确认别名存在 SELECT * FROM SYSCAT.TABLES WHERE TABNAME = 'TEMPL' AND TYPE = 'A'; -- 删除别名后重新建表 DROP ALIAS JLU.TEMPL; CREATE TABLE JLU.TEMPL (ID INTEGER, NAME VARCHAR(50), SALARY DECIMAL(10,2));

TYPE = 'A'表示别名，'T'才是表。删之前务必确认这个别名没被别的程序引用，否则会连带打断依赖它的查询。

4.2 空值统一显示为“空”

结果集里null直接打印会显示null字样，GUI 里更难看。做法是在取值时判断：

Object val = rs.getObject("NAME"); String display = (val == null) ? "空" : val.toString();

getObject()对任何列都返回对象，判空后再转字符串，比按类型分别getString/getInt再判wasNull()更省事。注意getInt返回 0 时无法区分“真是 0”还是“null”，必须配合rs.wasNull()，这是新手常踩的坑。

4.3 异常统一走对话框

违反约束、类型不匹配、溢出、非法符号这几类操纵错误，统一在catch (SQLException e)里用JOptionPane.showMessageDialog弹出，把getErrorCode()和getMessage()拼进去。别只弹一句“操作失败”，把 SQLCODE 带上，排查时能直接对号入座。

5. 避坑清单：五条血泪经验

• 现象：授权后仍报权限不足。原因：授权语句执行在错误的 schema 上下文，或连接未重连。解决：授权用全限定名，授权后关闭旧连接重新getConnection。
• 现象：executeUpdate返回正数但数据没变。原因：setAutoCommit(false)后漏了commit()。解决：事务块内 commit/rollback 成对写，用 try-catch 包住。
• 现象：建表报已存在却查不到表。原因：同名别名占用命名空间。解决：查SYSCAT.TABLES的TYPE字段，删别名再建表。
• 现象：数值放大后类型转换溢出。原因：DECIMAL精度不够。解决：查SYSCAT.COLUMNS确认精度，应用层做范围校验或调大字段精度。
• 现象：getInt拿到 0 分不清是零还是空。原因：基本类型无法表达 null。解决：取值后紧跟rs.wasNull()判断，或统一用getObject。

6. 快速定位：从 SQLCODE 到根因的三步法

排这类 JDBC 故障，我习惯先抓 SQLCODE，再对表，最后验事务。第一步，所有SQLException都把getErrorCode()、getSQLState()、getMessage()三个值打全，SQLCODE 是 DB2 给的精确错误号，比 message 文本可靠得多。第二步，拿 SQLCODE 对常见表：-551查权限、-204查对象名和 schema、-302查类型转换、-803查约束冲突。第三步，凡是“执行成功但没生效”的，一律先查getAutoCommit()的返回值，再确认有没有commit()。

验证连接和权限是否真的通了，别靠猜，跑一段最小代码：

try (Connection c = DriverManager.getConnection("jdbc:db2:sample", "db2admin", "db2admin"); Statement s = c.createStatement(); ResultSet rs = s.executeQuery("select count(*) from JLU.EMPLOYEE")) { rs.next(); System.out.println("rows=" + rs.getInt(1)); // 能出数就说明权限和对象名都对 } catch (SQLException e) { System.out.println("code=" + e.getErrorCode() + " state=" + e.getSQLState()); }

这段代码同时验证驱动加载、连接串、权限、对象名四件事，任何一环有问题都会在 catch 里暴露 SQLCODE。从那以后我每次换环境连库，都强制先跑一遍这个最小查询再动业务代码，省下的排查时间比写它的时间多得多。希望帮到你。

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