简介：这份文档面向JSP与数据库交互的初学者及小型Web项目开发者，聚焦于用JSP通过JDBC-ODBC桥连接ACCESS数据库并读取数据的完整实现思路。压缩包内仅含1个doc文件，约31KB，以图文与代码结合的方式呈现建库、部署与访问的全过程。内容围绕创建test.mdb数据库及username表、将数据库文件放入Tomcat指定目录、编写JDBCAccess.jsp等环节展开，并给出加载sun.jdbc.odbc.JdbcOdbcDriver驱动、拼接连接字符串、执行查询与遍历结果集的示例代码，同时强调关闭ResultSet、Statement与Connection以释放资源，附带异常捕获与错误信息输出。已有241人学习，适合作为理解JDBC连接原理、迁移到MySQL等关系型数据库的入门参考。
1. 从一份“上古”JSP连Access代码说起：它到底还能不能跑
翻出一份JDBCAccess.jsp的源码包，第一反应往往是：这东西现在还能用吗？答案是——能，但只在特定环境里能。这份资源的核心，是用 JSP 通过 JDBC-ODBC 桥接驱动去读一个test.mdb文件，把username表里的uid、pwd两列打印到页面上。它解决的是“小型 Web 项目或课程实践里，怎么让 Java 页面读到 Access 数据”这个最朴素的问题，适合还在用 Tomcat 6/7 那套老栈、需要快速验证数据通路的从业者和学生。但它的边界也很硬：驱动是 JDK 自带的sun.jdbc.odbc.JdbcOdbcDriver，JDK 8 之后已被移除，所以这份代码不是拿来就能跑，得先搞清楚它依赖什么。下面按“资源是什么 → 怎么搭 → 坑在哪 → 怎么验证”的顺序拆开讲，每一步都落到能抄的参数和命令上。
2. 拆解 JDBC-ODBC 桥接链路：驱动、连接串与路径三件事
这份资源看起来只是一个 JSP 文件，实际背后是一条四段式链路：JSP 容器 → JDBC-ODBC 桥 → ODBC 数据源驱动 →.mdb文件。任何一段断了，页面就只剩一句“数据库连接错误”。所以动手之前，先把这条链路上三个关键参数吃透，比盲目复制代码有用得多。
2.1 为什么是 JdbcOdbcDriver，而不是纯 JDBC 驱动
Access 没有官方纯 Java 的 JDBC 驱动，业界能用的方案基本就两条：一条是 JDBC-ODBC 桥（sun.jdbc.odbc.JdbcOdbcDriver），靠操作系统里的 ODBC 驱动管理器去读.mdb；另一条是第三方商业或开源驱动（如 UCanAccess），走纯 Java 解析。这份资源选的是前者，原因是零额外依赖——JDK 6/7 自带这个桥，Tomcat 起来就能用，不需要往WEB-INF/lib里丢 jar。
代价也很明确：桥接驱动依赖 Windows 上的Microsoft Access Driver (*.mdb)，也就是系统里得装了对应位数的 Office 或 Access Database Engine。32 位 ODBC 驱动和 64 位 JVM 不匹配，是这条链路最常见的翻车点。常见做法是：JVM 是 32 位就装 32 位驱动，是 64 位就装 64 位驱动，两边位数必须对齐。如果你在 Linux 上跑，这条路基本走不通，得换 UCanAccess。
连接串的写法也值得单独说。资源里用的是：
jdbc:odbc:Driver={Microsoft Access Driver (*.mdb)};DBQ=<物理路径>这里DBQ后面必须是绝对物理路径，不能是相对路径，也不能是 URL。代码里用application.getRealPath("data/test.mdb")把 Web 路径转成磁盘路径，就是为了满足这个要求。花括号里的驱动名必须和 ODBC 管理器里显示的完全一致，多一个空格都会报“找不到驱动程序”。
2.2 数据库文件放哪：getRealPath 的路径换算逻辑
资源要求把test.mdb放到webapps/ROOT/data/下，代码里写String spath = "data/test.mdb"，再用application.getRealPath(spath)转物理路径。这个设计的好处是路径跟着应用走，换机器不用改代码；坏处是它把数据文件塞进了部署目录，重新部署 war 包时容易被覆盖。
我一般会把.mdb放到容器外的固定目录，比如D:/appdata/test.mdb，然后连接串直接写死绝对路径，或者用 JNDI 数据源配。这样部署和升级互不干扰。如果坚持用资源里的相对路径方案，至少确认getRealPath返回的不是 null——在某些容器配置下（比如未解压的 war 部署），它可能返回空，后面拼出来的连接串就是DBQ=null，报错信息还特别含糊。
下面这段是路径换算的最小验证代码，可以单独放一个 JSP 里先跑通再谈连库：
<%@ page contentType="text/html; charset=gb2312" import="java.io.File" %> <% // 把 Web 路径换算成磁盘物理路径，先确认文件真实存在 String spath = "data/test.mdb"; String dbpath = application.getRealPath(spath); out.print("物理路径: " + dbpath + "<br>"); if (dbpath != null) { File f = new File(dbpath); out.print("文件存在: " + f.exists() + "<br>"); out.print("文件大小: " + f.length() + " 字节<br>"); } else { out.print("getRealPath 返回 null，检查部署方式<br>"); } %>逻辑说明：application.getRealPath依赖 ServletContext 对真实路径的映射，只有容器把应用解压到磁盘上才有效。参数spath是相对于 Web 应用根目录的路径，前面不要带/。如果exists()返回 false，先别改 JDBC 代码，问题在文件没放对位置。这一步能挡掉大约一半的“连接失败”误报。
2.3 建库建表：字段类型与连接串的对应关系
资源里username表只有uid、pwd两个文本字段，这是最小可验证结构。建表时有两个细节容易忽略：一是 Access 的“文本”类型默认长度 255，够用；二是字段名不要用 Access 保留字（如password、date），pwd这种缩写反而安全。如果表名或字段名带空格、中文，SQL 里必须用方括号包起来，比如select * from [user name]，否则解析报错。
连接串里的user和password在资源里留空，因为未设密码的.mdb不需要认证。一旦你给 Access 文件加了数据库密码，就得在连接串里补UID=...;PWD=...，或者用DriverManager.getConnection(url, user, password)三参版本。注意这里的密码是 Access 文件级密码，不是 Windows 登录密码，两者别混。
3. 把 JSP 跑起来：环境搭建、代码改造与结果验证
链路搞清楚之后，落地就是三步：把老 JDK 和 Tomcat 配好、把资源里的 JSP 按你的实际路径改对、启动后看页面输出。这一步的难点不在写代码，而在环境版本和字符集这两个“隐形参数”。
3.1 环境版本锁定：JDK 7 + Tomcat 6/7 是硬约束
sun.jdbc.odbc.JdbcOdbcDriver在 JDK 8 里被标记移除，JDK 9 之后彻底没有。所以这份资源要跑，JVM 必须是 JDK 6 或 7。Tomcat 6/7 对 Servlet 规范的支持也刚好匹配application.getRealPath的用法。如果你机器上只有 JDK 17，别硬改代码去兼容，直接换 UCanAccess 方案，或者单独装一个 JDK 7 跑这个 demo。
环境变量要确认JAVA_HOME指向 JDK 7，CATALINA_HOME指向 Tomcat 目录。启动前用java -version核对，别让系统 PATH 里的高版本 JDK 抢了先。这一步是血泪经验：很多人代码没错，就是 JVM 版本不对，报ClassNotFoundException: sun.jdbc.odbc.JdbcOdbcDriver，然后花半天去查 jar 包，其实根本没这个 jar，类在 rt.jar 里。
3.2 改造 JDBCAccess.jsp：异常信息要打全
资源里的 catch 块只打了e.getMessage()，信息量太少。排查连接问题时，至少要把异常类名和堆栈首行打出来。下面是我改过的版本，保留了原逻辑，只增强了错误输出和资源关闭的健壮性：
<%@ page contentType="text/html; charset=gb2312" language="java" import="java.sql.*" %> <meta http-equiv="Content-Type" content="text/html; charset=gb2312"> <% Connection conn = null; Statement stmt = null; ResultSet rs = null; try { // 1. 路径换算，确认 mdb 文件位置 String spath = "data/test.mdb"; String dbpath = application.getRealPath(spath); // 2. 拼接 ODBC 连接串，DBQ 必须是绝对物理路径 String url = "jdbc:odbc:Driver={Microsoft Access Driver (*.mdb)};DBQ=" + dbpath; // 3. 加载桥接驱动（仅 JDK 6/7 可用） Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); // 4. 建立连接，未设密码时 user/password 传空串 conn = DriverManager.getConnection(url, "", ""); // 5. 创建可滚动、可更新的语句对象 stmt = conn.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_UPDATABLE); // 6. 查询并遍历 rs = stmt.executeQuery("select * from username"); while (rs.next()) { out.print("用户名:" + rs.getString("uid")); out.print(" 密码:" + rs.getString("pwd") + "<br>"); } out.print("<br>数据库连接成功！"); } catch (Exception e) { // 打全异常类名，方便定位是驱动、路径还是 SQL 问题 out.print("数据库连接错误：" + e.getClass().getName() + "<br>"); out.print("错误信息：" + e.getMessage() + "<br>"); } finally { // 逆序关闭，每个都判空，避免空指针掩盖真实异常 if (rs != null) try { rs.close(); } catch (Exception ignored) {} if (stmt != null) try { stmt.close(); } catch (Exception ignored) {} if (conn != null) try { conn.close(); } catch (Exception ignored) {} } %>逻辑说明：createStatement的两个参数分别指定结果集可滚动敏感、可更新，资源里这么写是为了后续可能做rs.updateXxx，纯查询场景用默认的createStatement()也行。getConnection三参版本显式传空用户名密码，比单参版本更清晰。finally里逐个判空关闭，是因为如果conn建立失败，stmt和rs都是 null，直接调close()会抛空指针，把真正的连接异常盖掉——这是原代码最容易误导人的地方。
参数调整点：spath改成你的实际相对路径；select * from username里的表名按你的库改；如果 Access 文件设了密码，把getConnection改成getConnection(url, "admin", "你的密码")。
3.3 启动与验证：从页面输出反推链路状态
把 JSP 丢进webapps/ROOT/下，启动 Tomcat，访问http://localhost:8080/JDBCAccess.jsp。页面输出分三种情况，对应链路的不同断点：
| 页面现象 | 断点位置 | 排查方向 |
|---|---|---|
ClassNotFoundException | 驱动加载 | JVM 版本高于 7，或类名拼错 |
java.sql.SQLException: [Microsoft][ODBC 驱动程序管理器] 未找到数据源名称 | ODBC 驱动 | 系统未装 Access 驱动，或位数不匹配 |
java.sql.SQLException: [Microsoft][ODBC Microsoft Access Driver] 找不到文件 | DBQ 路径 | getRealPath返回 null 或文件没放对 |
| 正常输出用户名密码 | 全链路通 | 可进入下一步改造 |
这张表是我排错时最常用的对照，基本能覆盖八成问题。验证通过后，别急着删 demo，把它留作回归测试页——以后换驱动、换路径，先跑它确认链路没断。
4. 避坑与排查：五条踩过的真实记录
这条老链路的问题高度集中，下面五条是按“现象 → 原因 → 解决”整理的踩坑记录，每条都对应一个具体参数或环境点。
4.1 报“未找到数据源名称且未指定默认驱动程序”
现象：页面抛出SQLException，提示 ODBC 驱动管理器找不到数据源。原因：系统里没装Microsoft Access Driver (*.mdb)，或者 JVM 是 64 位而装的是 32 位驱动。解决：打开“ODBC 数据源管理器”，看“驱动程序”页签里有没有这个驱动名；没有就装对应位数的 Access Database Engine，装完重启 Tomcat。位数对齐这条没有捷径，32 对 32、64 对 64。
4.2 连接串里 DBQ 拼出 null
现象：报错信息里路径部分是DBQ=null。原因：application.getRealPath("data/test.mdb")返回了 null，通常是应用以未解压 war 方式部署，或spath前面多了/。解决：先用 2.2 节的验证 JSP 打印dbpath，确认非 null 再连库；部署方式改成解压目录，或改用容器外绝对路径。
4.3 中文用户名显示成乱码
现象：uid里存的是中文，页面输出问号或方块。原因：JSP 页面charset=gb2312，但 Access 文件或 ODBC 驱动按其他编码解析，两边不一致。解决：统一成gb2312或GBK，页面指令、meta、数据库字段编码三处对齐；如果数据本身是 UTF-8 存的，页面也得改 UTF-8。老项目里编码不统一是常态，别只改一处就以为好了。
4.4 升级 JDK 后代码突然跑不动
现象：同一份 JSP，换台机器就报ClassNotFoundException: sun.jdbc.odbc.JdbcOdbcDriver。原因：新机器装的是 JDK 8 及以上，桥接驱动已被移除。解决：要么降回 JDK 7 跑 demo，要么迁移到 UCanAccess，把驱动类改成net.ucanaccess.jdbc.UcanaccessDriver，连接串改成jdbc:ucanaccess://<路径>，并把相关 jar 放进WEB-INF/lib。迁移时 SQL 基本不用改，但日期、布尔类型的映射行为有差异，要单独测。
4.5 连接没关导致文件被锁
现象：反复刷新页面后，.mdb文件无法在 Access 里打开，提示被占用。原因：异常路径下conn没关闭，ODBC 连接持有文件句柄。解决：按 3.2 节的finally写法逆序关闭；调试期间如果文件已被锁，重启 Tomcat 释放句柄。这条在开发阶段特别容易中招，因为大家习惯改完代码直接刷新，不重启容器。
5. 从 demo 到可用：连接池与迁移路径的取舍
demo 跑通只说明链路通，真要用在小项目里，还得解决两个问题：每次请求都新建 ODBC 连接，开销大且容易锁文件；JDK 版本一旦升级，整条链路作废。前者靠连接池，后者靠驱动迁移，两件事可以分开做。
连接池方面，Tomcat 自带的 DBCP 就能配。在META-INF/context.xml里声明一个 Resource：
<Context> <Resource name="jdbc/accessDS" auth="Container" type="javax.sql.DataSource" driverClassName="sun.jdbc.odbc.JdbcOdbcDriver" url="jdbc:odbc:Driver={Microsoft Access Driver (*.mdb)};DBQ=D:/appdata/test.mdb" maxActive="10" maxIdle="5" maxWait="3000" username="" password="" validationQuery="select count(*) from username" /> </Context>JSP 里改成从 JNDI 取连接：
// 通过 JNDI 获取池化连接，避免每次请求新建 ODBC 会话 javax.naming.Context initCtx = new javax.naming.InitialContext(); javax.sql.DataSource ds = (javax.sql.DataSource) initCtx.lookup("java:comp/env/jdbc/accessDS"); Connection conn = ds.getConnection();参数说明：maxActive控制并发连接上限，Access 文件级锁对并发很敏感，建议不超过 10；validationQuery用一条轻量查询探活，避免拿到失效连接；maxWait是取连接的最长等待毫秒数，超时抛异常而不是无限挂起。注意DBQ这里写的是容器外绝对路径，和 demo 的相对路径方案不同，这是有意的——池化连接生命周期长，路径必须稳定。
迁移路径方面，如果项目还有几年寿命，我建议直接上 UCanAccess，别在桥接驱动上继续投入。迁移清单就三件事：替换驱动类名、替换连接串前缀、把 jar 依赖补齐（ucanaccess、jackcess、hsqldb等）。迁移后 JDK 版本不再受限，Linux 也能跑，代价是启动时多加载几个 jar，内存占用略升。判断标准很简单：如果这个 Access 数据只是临时验证、项目周期短，留在 JDK 7 + 桥接驱动最省事；如果要长期维护或换服务器，迁移越早越好。
验证迁移是否成功，别只看页面能不能出数据，还要跑一遍边界用例：空表、中文数据、带密码的库、并发 5 个请求同时刷新。我一般会写一个简单的压测页，循环请求 20 次看连接是否泄漏——Access 被锁死这种事，往往就是并发下连接没归还导致的。从那以后我每次接这类老栈项目，都强制先跑一遍“路径验证 → 单连接查询 → 池化并发”这三步，再谈业务代码。希望帮到你。
本文还有配套的精品资源，点击获取
