VB6+Access数据库操作详解：连接、查询与增删改实战

简介：面向VB6开发者的Access数据库操作指南，聚焦ADO组件在桌面程序中的实际应用，解决新手在数据查询、添加、删除、更新以及连接管理上的常见困惑。资源为单个PDF文档，大小仅26KB，篇幅精简但都是可落地的代码片段。已有99人学习浏览，适合快速查阅。文档以多个实例展开：例1演示SELECT查询、Recordset遍历及Do While循环将字段值填充到组合框；例2构建简易用户登录系统，涵盖按用户名查询、密码比对，并附带INSERT、DELETE、UPDATE三种SQL语句通过Conn.Execute执行的写法；例3与例4则给出两种连接Access数据库的字符串写法，涉及Provider=Microsoft.Jet.OLEDB.4.0参数及连接状态判断。此外，还系统梳理了在VB6中引用ADO对象库、定义Connection与Recordset对象、编写SQL、遍历结果集以及最后关闭连接释放资源等关键知识点。整份资料代码结构清晰，注释直观，适合初学者边看边练，也可作为日常开发时的速查手册。

1. 无从下手的校园系统，为什么最后都卡在数据库操作上

不管是做学生信息管理、图书借阅还是成绩查询，VB6搭配Access几乎是一代人的入门标配。你大概已经发现，网上搜“VB6连接Access”能搜出一堆代码，但真正拷进工程里能一次跑通的寥寥无几。问题往往不是SQL写错，而是连接字符串不对、引用没勾、记录集游标选错，或者数据库路径写死导致换台电脑就崩。这份《VB6+Access编程中的数据库操作方法.pdf》的价值就在于，它用四个完整实例把“连接—查询—增删改—状态判断”这条线串起来了，每一段都能直接抄进工程跑通。适合正在做毕业设计、课程设计，或者维护老系统但不想反复翻旧帖的人。与其东拼西凑看碎片，不如把这份PDF里的套路一次吃透。

2. 连接Access：连接字符串、引用库与连接状态判断

2.1 为什么偏偏要引用“Microsoft ActiveX Data Objects 2.7 Library”

VB6里操作Access数据库，最常见的技术栈是ADO（ActiveX Data Objects），而不是DAO或RDO。ADO是微软为统一数据访问推出的高层接口，它不关心你连的是Access、SQL Server还是Oracle，只要底层有对应的OLE DB Provider，上层代码可以几乎原样复用。这一点在PDF的例1、例2、例3里体现得很明显：所有例子的核心对象都是ADODB.Connection和ADODB.Recordset，差别只在连接字符串。

打开VB6的“工程”菜单，选“引用”，在弹出的对话框里勾选Microsoft ActiveX Data Objects 2.7 Library。如果你的机器上装的是更高版本，比如2.8或者6.0，也可以勾选，代码层面完全兼容。注意：引用对话框里可能出现多个ADO版本项，勾选一个即可，不要全勾，否则可能出现类型定义冲突。勾选之后，代码里才能直接声明Dim cn As New ADODB.Connection，否则VB6会提示“用户类型未定义”。

很多初学者在这里栽的第一个跟头是：代码是从网页上复制的，但网页作者用的是ADODB.Connection，而你自己用的是DAO.Database，两套对象模型混在一起，编译必然报错。搞混DAO和ADO的本质区别就在于，前者是Jet引擎的直系后代，后者是通用的OLE DB接口。做Access数据库开发，尤其是要兼顾后续迁移到SQL Server的场景，选ADO更靠谱。

' 在通用声明区定义连接对象和记录集对象 Dim cn As New ADODB.Connection Dim rs1 As New ADODB.Recordset Dim sql As String

这段代码定义了三个关键变量：cn是连接对象，负责与数据库建立管道；rs1是记录集对象，负责保存查询结果；sql只是普通字符串变量，存放SQL语句。New关键字意味着每次代码执行到这一行，都会创建对象实例，不需要手动Set再赋值。

如果不想在窗体级声明，也可以写在函数内部，但那样每个函数都要重复声明，代码冗余。我的习惯是：只有一个窗体的小工具，就放窗体通用区；多窗体项目，建议放到标准模块（.bas）里，方便所有窗体共享同一个连接管理函数。

2.2 连接字符串拆解：Provider、Data Source与Persist Security Info

例3里给出了一条典型的Access连接字符串：

connect_string = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & App.Path & "\aaa.mdb;Persist Security Info=False"

这条字符串拆开看有四个部分。Provider=Microsoft.Jet.OLEDB.4.0指定了OLE DB提供程序，Jet 4.0适用于Access 97到2003格式的.mdb文件。如果你用的是Access 2007以后的.accdb格式，就要改用Provider=Microsoft.ACE.OLEDB.12.0，这个Provider默认不在Windows里，需要单独安装“Microsoft Access Database Engine 2010 Redistributable”，这是老机器上最容易翻车的环节之一。Data Source=后面跟数据库文件的完整路径，可以是绝对路径如D:\mydb.mdb，也可以是相对路径如App.Path & "\aaa.mdb"。App.Path是VB6运行时的当前应用程序目录，你用VB6自带的打包工具发布程序时，程序装到哪，数据库就放到哪，不用改代码。Persist Security Info=False表示连接成功后不保存密码信息，防止连接字符串在内存中被泄露，属于安全项，一般照抄不用改。

连接字符串里还有一个常见参数User ID和Password，用于访问带密码的Access数据库。Access数据库设置密码后，连接字符串要改成这样：

strConn = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=D:\mydb.mdb;Jet OLEDB:Database Password=123456"

注意Jet OLEDB:Database Password这个参数名和直接写Password不一样，前者是Jet引擎特有的，后者会被忽略。很多网上的代码没写清楚这一点，导致带密码的库永远连不上。

Private Sub Form_Load() Dim cnn As ADODB.Connection Dim my_recordset As ADODB.Recordset Dim connect_string As String Dim statestring As String Set cnn = New ADODB.Connection Set my_recordset = New ADODB.Recordset ' 连接Access数据库 connect_string = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & App.Path & "\aaa.mdb;Persist Security Info=False" cnn.Open connect_string Select Case cnn.State Case adStateClose statestring = "adStateClosed" Case adStateOpen statestring = "adStateOpen" End Select ' 显示连接的状态 MsgBox "连接成功！", , statestring ' 对wzdz表进行查询操作 my_recordset.Open "Select * from wzdz", cnn my_recordset.Close End Sub

例3这段代码演示了两个动作：打开连接、检查状态。cnn.State是ADO连接对象的一个属性，返回的是连接当前状态。adStateClose的枚举值是0，adStateOpen的枚举值是1，理论上还可以是adStateConnecting（2）和adStateExecuting（4），后者属于异步操作中的瞬时状态，同步模式下几乎看不到。

检查状态这个动作在实际开发中价值很大。比如一个程序要跑在U盘里，用户拔了U盘或者换了盘符，连接串里的路径就会失效，cnn.Open会抛异常。如果你在调用cnn.Open之前先检查文件是否存在，再检查连接状态，就能给用户一个明确的提示，而不是一个“运行时错误‘-2147467259（80004005）’”这种让新手懵圈的对话框。这里还藏着一个值得注意的细节：my_recordset.Open "Select * from wzdz", cnn这行代码能跑的前提是数据库里确实存在wzdz这张表。表名写错会在运行时才报错，VB6的编辑器不会帮你检查SQL里的表名和字段名，这是所有初学者的共同槽点。我的经验是，写完SQL后先在Access里用查询设计视图验证一遍，再贴回VB6代码，能省下一个小时的排错时间。

2.3 记录的增、删、改与Execute方法

例2后半部分给出了三条增删改SQL，是整个PDF里含金量最高的部分。它们的共同特征是使用Conn.Execute SQL来执行，而不是用Recordset对象来承载结果。

' 添加记录 SQL = "Insert Into [UserInfo](User,Password) Values('aaaa','1234')" Conn.Execute SQL ' 删除记录 SQL = "Delete From [UserInfo] Where User='aaaa'" Conn.Execute SQL ' 更新记录 SQL = "Update [UserInfo] Set Password='abcdefg' Where User='aaaa'" Conn.Execute SQL

Conn.Execute适合执行不返回结果集的SQL，比如INSERT、DELETE、UPDATE，还有建表语句（CREATE TABLE）和删表语句（DROP TABLE）。执行完这三条语句后，可以用Conn.Execute的第二个参数来接收受影响的行数，写法是这样：

Dim rowsAffected As Long Conn.Execute SQL, rowsAffected MsgBox "影响了 " & rowsAffected & " 行"

rowsAffected回传一个长整型数值，表示这条SQL真正动了多少条记录。调试阶段这个数字非常有用。比如你执行UPDATE，发现rowsAffected是0，那基本可以断定WHERE条件没匹配到任何记录，要么用户名写错，要么表里根本没有这条数据。比用MsgBox弹窗的方式更隐蔽的是，把受影响行数累计起来写进日志文件，这样用户反馈问题时你能拿到第一手证据。

这里必须提醒一个Access的经典坑：Access对SQL语句中的分号和括号处理方式和SQL Server不完全一致。上面的INSERT语句，在Access的查询设计器里可以写成INSERT INTO UserInfo(User,Password) VALUES('aaaa','1234')，不需要在末尾加分号。但在VB6的字符串里，如果你手贱加了分号传给Conn.Execute，Jet引擎通常也能容忍，可一旦字段名或表名与Access保留字冲突，比如User，就必须加方括号[User]。PDF例2里的表名UserInfo带上了方括号，字段User也带了方括号，这就是老手和新手的区别——新手不知道哪些词是保留字，老手一律给表名和字段名套方括号，从根上消除这类隐患。

2.4 连接资源不释放，最终拖垮整个程序

例1和例2都提到了rs1.Close，但没有系统的资源管理逻辑。这个资源释放问题在短小的示例代码里看不出危害，一旦放到实际程序里，比如一个窗体频繁打开关闭，连接对象不断新建不释放，内存就会持续上涨。VB6的程序跑上一整天后变得越来越慢，点按钮半天没反应，十有八九是连接泄漏。这不是玄学，是COM对象的引用计数没有被正确递减。

一个系统的资源管理习惯应该是：

Private Sub Form_Unload(Cancel As Integer) If Not rs1 Is Nothing Then If rs1.State = adStateOpen Then rs1.Close Set rs1 = Nothing End If If Not cn Is Nothing Then If cn.State = adStateOpen Then cn.Close Set cn = Nothing End If End Sub

Set ... = Nothing这一步是在显式释放COM对象引用。VB6没有垃圾回收机制，你不把对象引用置空，系统就认为对象还在使用中，占用的内存和底层连接句柄就一直不释放。对于一个长期运行的程序，这个习惯比代码本身的功能正确性更重要。

3. 查询结果处理：从Recordset取值到控件填充

3.1 打开记录集前要想清楚的三个参数：游标类型、锁定类型和连接

例1展示了最基本的记录集遍历方式：

sql = "select * from 表名" rs1.Open sql, cn rs1.MoveFirst Do While Not rs1.EOF Combo1.AddItem rs1("字段名") rs1.MoveNext Loop rs1.Close

这段代码能跑，但只能算入门写法。rs1.Open方法的完整签名是Recordset.Open Source, ActiveConnection, CursorType, LockType, Options，后三个参数都有默认值，而默认值在企业级开发场景中往往不是最优解。PDF例1完全没有指定游标类型和锁定类型，意味着它采用的是默认的前向游标（adOpenForwardOnly）和只读锁定。前向游标只能从第一条记录往后走，不能回滚，所以代码里才有rs1.MoveFirst这一句，如果数据库已经在第一条记录上，这行是多余的，但如果前一次遍历停在记录集末尾，MoveFirst能把指针拉回开头。

在实际业务系统里，我更推荐显式指定游标参数：

rs1.Open "select * from 表名", cn, adOpenKeyset, adLockReadOnly

adOpenKeyset（键集游标）允许在记录集内自由移动，同时只能看到别人插入的新记录，看不到别人删除的记录；adLockReadOnly表示只读，适合单纯查询场景，性能最好。如果要通过Recordset直接修改数据，就得用adLockOptimistic，但在这个场景下，直接用Conn.Execute执行SQL更稳妥。

3.2 为什么RecordCount经常等于-1

新手最常撞的坑之一是rs1.RecordCount返回-1。这不是Bug，而是游标类型的限制。当你使用前向游标（默认值）打开记录集时，Jet引擎无法确定总行数，所以RecordCount属性返回-1。要拿到准确的行数，必须使用adOpenKeyset或adOpenStatic游标。这个问题在PDF例3里没有直接体现，因为例3用的是默认的隐式游标，它只关心能不能遍历，不关心总共几条。

判断记录集是否为空的可靠方式不是看RecordCount，而是检查rs1.EOF和rs1.BOF。例2里的登录代码就是这样处理的：查询结果若为空，EOF为True。在adOpenKeyset游标下，若查询结果非空、且游标停在第一条记录上，此时EOF和BOF均为False，但这个状态会让人困惑——BOF指向第一条记录之前的位置，EOF指向最后一条记录之后的位置，一个非空记录集的指针在“第一条记录上”时，BOF是False的。

3.3 向Combo1添加记录，慢在AddItem而不是数据库

例1的核心动作是Combo1.AddItem rs1("字段名")。单行代码没毛病，但如果你循环往Combo或ListBox里AddItem几千条记录，界面会明显卡顿。原因是AddItem每次调用都会触发控件的重绘逻辑，一条条添加就是几千次重绘。

老手会这样做：

Combo1.Visible = False Combo1.Clear Do While Not rs1.EOF Combo1.AddItem rs1("字段名") rs1.MoveNext Loop Combo1.Visible = True

先把控件隐藏，再批量填充数据，填充完成后再显示出来。这个技巧在数据量达到几百条以上时体感差异非常明显。还有一种更彻底的方式是直接给控件的List属性赋一个字符串数组，一次性完成填充，但这要求先用循环把记录集数据搬进数组，代码量并没有减少，优势是控件重绘只发生一次，速度最快。

Dim itemList() As String Dim i As Long i = 0 ReDim itemList(0) Do While Not rs1.EOF ReDim Preserve itemList(i) itemList(i) = rs1("字段名") i = i + 1 rs1.MoveNext Loop Combo1.List() = itemList

ReDim Preserve虽然每次都会重新分配数组空间，但在几百条记录级别，性能开销远小于多次重绘控件的开销。把这段代码和直接AddItem做一个对比测试，你会直观地感受到差异。

3.4 遍历时的空值和Null处理

Access数据库的字段允许为Null，和VB6的Empty、空字符串都不是一回事。当rs1("字段名")的值是Null时，用Combo1.AddItem直接添加会得到一个空项，看起来像一行空白，排查问题时很难发现。更好的写法是做一次空值转换：

Dim fieldValue As Variant fieldValue = rs1("字段名") If IsNull(fieldValue) Then fieldValue = "" Combo1.AddItem fieldValue

IsNull是VB6内置函数，专门用于判断Variant变量是否为Null。这个转换不仅让显示更干净，还能避免后续对字段值做字符串拼接时出现“无效使用Null”之类的运行时错误。记住这个规则：任何一个从数据库取出来的字段，都可能在它身上发生Null，处理之前先做个判空。

4. 用户登录系统实例：从UI到数据库的逻辑串起来

4.1 例2的业务逻辑：为什么先判断TextBox内容是“1”或“2”

例2的用户登录代码有一段看似奇怪的逻辑：先判断文本框输入内容是否为"1"或"2"，是才继续弹窗输入用户名密码。这在实际系统里不常见，更像是示例代码用来演示分支逻辑的占位写法。真正的业务系统里，这个判断通常用来区分登录身份，比如输入1代表学生登录，输入2代表管理员登录。

我们可以把这段代码改造成一个更合理的登录函数，返回登录结果给调用方：

Private Function CheckLogin(userName As String, password As String) As Boolean Dim Conn As New ADODB.Connection Dim Rs As New ADODB.Recordset Dim sql As String Conn.Open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & App.Path & "\mydb.mdb" ' 使用参数化查询，避免SQL注入风险 sql = "Select * From [UserInfo] Where User=? And Password=?" Set Rs = Conn.Execute(sql, , adCmdText) CheckLogin = (Rs.State = adStateOpen And Not Rs.EOF) Rs.Close Conn.Close Set Rs = Nothing Set Conn = Nothing End Function

这里改动最大的地方是把原来的动态拼接SQL改成了参数化查询。原代码的"where User='" & UserName & "'"是典型的SQL注入写法，如果用户名里输入'; DROP TABLE UserInfo; --，Access会执行这条删表语句。虽然示例代码用于教学，但这种写法一旦留到生产环境就是灾难。自己写练习代码怎么方便怎么来，但凡是给别人用的系统，必须把参数化查询作为最低底线。

VB6里的Conn.Execute支持用?占位符，但需要配合Command对象才能真正传参。上面的写法是把?当成普通字符传给Jet引擎，并不具备参数化能力。真正参数化的实现要这样：

Dim cmd As New ADODB.Command cmd.ActiveConnection = Conn cmd.CommandText = "Select * From [UserInfo] Where User=? And Password=?" cmd.Parameters.Append cmd.CreateParameter("p1", adVarChar, adParamInput, 50, userName) cmd.Parameters.Append cmd.CreateParameter("p2", adVarChar, adParamInput, 50, password) Set Rs = cmd.Execute

CreateParameter的四个参数依次是参数名、数据类型（adVarChar对应字符串）、方向（adParamInput表示输入参数）和最大长度。这段代码的价值在于：无论传入的userName是什么内容，它只会被当作字符串值，永远不会被解释成SQL语句的一部分。这就是参数化查询和字符串拼接的本质差别。

4.2 登录逻辑中的四个判定分支

梳理例2的判定逻辑，一共四层：第一层判断是否有权登录（s是否为1或2），第二层判断用户是否存在（Rs.EOF是否为True），第三层判断密码是否匹配，第四层按s值分支进入不同模块。这个结构适合入门但不适合复用，因为它把UI、业务逻辑和数据访问全搅拌在一个Command1_Click事件里。一旦窗体布局变动或者登录规则变化，就得在这个事件里反复改。

更清晰的拆法是把数据访问层单独封装一个模块，UI只负责调用和展示结果。对于一份教学PDF来说，例2的原始写法反而有利于初学者看清楚完整的数据流，所以没必要全盘否定。但要意识到：在生产系统里，这四层判断应该至少拆成两个函数，一个专门负责校验用户密码，一个专门负责把校验结果翻译成用户提示。

4.3 登录系统里容易忽视的记录集关闭时机

例2代码有两个分支都在Rs.Open之后做了Rs.EOF判断，但有的分支里直接MsgBox完就结束了，没有显式Rs.Close。如果Rs是过程级别的局部变量，过程结束时会自动释放；但例2里的Rs是用New创建的，释放时机由VB6决定，不一定在过程结束时立刻回收。在连续多次登录失败的场景下，每次登录都可能残留一个未关闭的记录集和连接，最终表现是登录功能越用越慢，直到系统提示“内存不足”。

所以不管哪个分支结束了，都要在过程退出前统一执行资源清理。一种常用的收尾写法是：

If Rs.State = adStateOpen Then Rs.Close If Conn.State = adStateOpen Then Conn.Close Set Rs = Nothing Set Conn = Nothing

把这四行放在模块末尾，而不是每个分支各写一遍，可读性和可维护性都更好。

4.4 使用App.Path做数据库路径的边界条件

App.Path在VB6中代表程序所在的目录，但它有一个边界条件：如果你的程序是放在磁盘根目录下，比如D:\，App.Path的值就是D:\，此时再做字符串拼接App.Path & "\aaa.mdb"，得到的路径是D:\aaa.mdb，没有问题。可如果你的程序在光盘上或者从网络驱动器启动，App.Path的返回值可能是只读路径，此时数据库文件没法写入，登录后做增删改都会报错。这个场景下，应该把Access数据库复制到用户的可写目录，比如App.Path改为Environ("APPDATA")再拼接。Environ("APPDATA")返回的是当前用户的Roaming目录，一般在C:\Users\用户名\AppData\Roaming，这里始终可写。

5. 避坑与常见问题：ADO在VB6里绕不开的那些坎

5.1 现象：连接字符串没写错，但提示“未找到提供程序”

原因：Access 2007以后的新格式.accdb文件不会认Jet 4.0 Provider。Jet 4.0只支持.mdb文件，如果你用Access 2016创建一个新数据库，默认格式是.accdb，然后再拿VB6里的Jet 4.0去连，就会报这个错。

解决：安装Access Database Engine，也就是ACE驱动，把Provider换成Microsoft.ACE.OLEDB.12.0。安装时注意位数，VB6是32位程序，必须安装32位版本的ACE引擎，安装64位版会导致VB6还是连不上。更精确地说，64位Windows默认可以运行32位VB6程序，但OLEDB Provider是COM组件，32位程序只能加载32位Provider，所以装ACE的时候选AccessDatabaseEngine.exe而不是AccessDatabaseEngine_x64.exe。

5.2 现象：INSERT语句执行，提示“语法错误（操作符丢失）”

原因：字段名或表名命中了Access保留字。Name、User、Date、Password、Value这些词都是Access的保留字，直接写进SQL会被解析器误解。例2里的User字段虽然加了方括号，但很多从PDF抄代码的人只抄了SQL主体，把方括号丢了。

解决：一律给SQL里的表名和字段名加上方括号。Insert Into [UserInfo]([User],[Password]) Values(...)，Select [User],[Password] From [UserInfo]。方括号是Access的SQL方言，SQL Server也同样支持，用这个习惯可以同时规避两个数据库的保留字问题。

5.3 现象：程序在开发机上正常，复制到别的电脑上数据库操作全部失败

原因：目标机器没有安装VB6运行时库，或者没有ACE/Jet引擎。VB6编译出的exe需要msvbvm60.dll这个运行库，而Jet引擎虽然Windows XP自带，Win7以上系统不一定完整保留。

解决：用VB6自带的“打包和部署向导”生成安装包，它会自动带上运行库。如果手头没有向导，也可以手动把msvbvm60.dll、oleaut32.dll等几个文件复制到目标机器，再把数据库文件放到和exe相同的目录下。ACE引擎则需要在目标机器上单独安装一次。实际操作中，我习惯做两件事：一是在程序启动时检测连接是否成功，失败则弹窗提示；二是把数据库连同脚本文件打包，让用户在安装时自动完成ACE引擎安装。

5.4 现象：Recordset.RecordCount返回-1，影响分页逻辑

原因：游标类型是前向游标，Jet引擎无法统计总行数。

解决：打开记录集时指定adOpenKeyset或adOpenStatic。如果需要精确的行数，就直接写一条SELECT COUNT(*) FROM 表名查询，用rs(0)取出数值，比依赖RecordCount更可靠。在数据量大的表上，COUNT(*)通常是毫秒级完成。

5.5 现象：程序执行UPDATE或DELETE，没有报错，但数据没变

原因：最可能是WHERE条件没匹配到任何记录，或者Access的Jet引擎把这条SQL解释成了事务内未提交的操作。第二种情况一般只在用了显式事务（BEGIN TRANSACTION）时出现。

解决：第一步用Conn.Execute SQL, rowsAffected拿受影响行数，如果是0，说明条件不成立。第二步，如果是UPDATE语句，先用相同的WHERE条件写一条SELECT，看看能查出几行，再做更新。这比盯着SQL句子看半天高效得多。还有一种隐蔽情况：数据库文件被设为只读属性，Jet引擎无法写入文件，解决办法是右键数据库文件，取消“只读”勾选。

5.6 现象：数据库密码是123456，但连接一直报错

原因：Access的密码有两种，一种是打开数据库的密码，在“以独占方式打开”的前提下设置，连接串用Jet OLEDB:Database Password传递；另一种是用户级安全机制（.mdw文件），那套机制在Access 2003以后逐渐废弃，用ADO连接时通常不生效。

解决：确认是在提供程序的所有选项卡里设置了数据库密码，连接串写法为Provider=Microsoft.Jet.OLEDB.4.0;Data Source=D:\mydb.mdb;Jet OLEDB:Database Password=123456。注意，密码有大小写区分，123456和123456之间不要出现空格。另外，设置过密码的数据库必须用独占方式打开，否则Access的连接串会拒绝访问。

6. 把示例代码打磨成可维护的模块：一个通用的DBHelper

例1到例4的代码场景各不相同，但它们有一个共同短板：数据库连接、SQL语句、结果处理没有分层。也就是说，窗体里既能看到连接串，又能看到SQL，还能看到界面填充逻辑。代码量小的情形下问题不大，一旦窗体增多、SQL复杂化，这种写法会让维护变成重体力活。这里给出一套我常用的改造方案：做一个标准模块，把连接、查询、执行三类操作收敛到三个函数里。

' 模块名：DBHelper.bas Public Function GetConnection() As ADODB.Connection Dim conn As New ADODB.Connection Dim dbPath As String dbPath = App.Path & "\mydb.mdb" conn.ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & dbPath & ";Persist Security Info=False" conn.Open Set GetConnection = conn End Function Public Function ExecuteSql(sql As String) As Long Dim conn As ADODB.Connection Set conn = GetConnection() conn.Execute sql, ExecuteSql conn.Close Set conn = Nothing End Function Public Function QueryRecordset(sql As String) As ADODB.Recordset Dim conn As ADODB.Connection Dim rs As New ADODB.Recordset Set conn = GetConnection() rs.Open sql, conn, adOpenKeyset, adLockReadOnly Set rs.ActiveConnection = Nothing Set QueryRecordset = rs conn.Close Set conn = Nothing End Function

GetConnection函数负责创建连接，ExecuteSql函数负责执行增删改并返回影响行数，QueryRecordset函数负责查询并返回一个与连接解绑的记录集。最后一个函数里的Set rs.ActiveConnection = Nothing是关键：断开记录集和连接的关联，这样调用方可以在连接关闭后继续使用记录集里的数据。否则一旦外层conn.Close，记录集就变成“无主”状态，读取数据时可能抛出“对象关闭时不允许操作”的错误。

调用方的代码就清爽多了：

Dim rs As ADODB.Recordset Set rs = QueryRecordset("Select * From [UserInfo]") Do While Not rs.EOF List1.AddItem rs("User") rs.MoveNext Loop rs.Close Set rs = Nothing

值得注意的是，QueryRecordset里打开记录集用了adOpenKeyset游标，这会立即取回所有匹配记录。如果表数据量达到几十万行，网卡和内存都会成为瓶颈。在这种场景下，我通常会改造一下，增加一个可选参数来控制是否用前向游标。前向游标的好处是边读边取，占用内存小，代价是不能随意移动指针。一个改造后的函数签名可以设计成：

Public Function QueryRecordset(sql As String, Optional cursorType As CursorTypeEnum = adOpenKeyset) As ADODB.Recordset

cursorType这个可选参数给了调用方灵活性：需要自由移动记录用Keyset，纯粹遍历填充列表用ForwardOnly，性能差异在数据量大时立竿见影。

最后再分享一个我保留至今的习惯：所有用到ADO的窗体，Form_Unload事件里强制判断一遍连接和记录集状态，不管是全局连接还是局部连接。这个习惯最早只是因为被资源泄漏弄怕了，后来发现它还能顺带暴露另一个问题——窗体卸载时记录集还开着，说明有查询没有正常收尾，多半有SQL异常被吞掉了。从那以后我经常会留一个私人的窗体模板，凡是我经手的VB6项目，Form_Unload都是同一套模子。希望这份PDF里提炼出的这套连接、查询、增删改的组合思路，能帮你在自己的项目里少走几步弯路。

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