RecordCount=-1？让 Codex 走 TaoToken 查 ADODB.RecordSet 游标

RecordCount-1让 Codex 走 TaoToken 查 ADODB.RecordSet 游标如果你在 ASP 里用Conn.Execute(SqlStr)或者用Server.CreateObject(ADODB.RecordSet)后执行Rs.Open SqlStr,Conn,CursorType,LockType明明数据库里有记录Rs.RecordCount却返回-1那这篇排障记录就是写给你的。这个现象通常不是 SQL 写错也不是数据库没有数据而是 ADODB.RecordSet 的游标位置和游标类型没有配对。今天我会用 Codex 走 TaoToken 的通道把 ASP 代码片段、RecordCount-1现象以及CursorLocation、CursorType取值一起交给它对照排查。TaoToken 官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentrecordcount_fix 先注册并创建 Key再把 Codex 的 Base URL 填https://taotoken.net/api就能让 Codex 在本地读取 ASP 代码、解释服务器游标为什么返回-1并给出CursorLocation改adUseClient、CursorType用Static(3)的对照改法。TaoToken 只提供 Key 和 Base URL不替代 ADO 游标逻辑也不去操作游标最终判断仍要回到代码和数据库驱动本身验证。一、问题现场RecordCount-1 为什么总在 ASP 游标上出现先还原最常见的两种写法。第一种是直接用连接对象执行 SQL% Dim Conn, Rs, SqlStr Set Conn Server.CreateObject(ADODB.Connection) Conn.Open 你的连接字符串 SqlStr SELECT * FROM 你的表 WHERE 条件 Set Rs Conn.Execute(SqlStr) Response.Write RecordCount Rs.RecordCount %第二种是先创建ADODB.RecordSet再调用Open% Dim Conn, Rs, SqlStr Set Conn Server.CreateObject(ADODB.Connection) Conn.Open 你的连接字符串 SqlStr SELECT * FROM 你的表 WHERE 条件 Set Rs Server.CreateObject(ADODB.Recordset) Rs.Open SqlStr, Conn, CursorType, LockType Response.Write RecordCount Rs.RecordCount %这两种写法都可能得到Rs.RecordCount -1。原因在于 ADO 游标默认不是客户端游标而是服务器游标。Rs.CursorLocation的默认值通常是adUseServer也就是服务器游标。服务器游标为了减少资源占用并不保证维护完整的结果集行数因此RecordCount可能返回-1。尤其当CursorType还是默认的adOpenForwardOnly(0)时只进游标更不会提供准确记录数。CursorType和RecordCount的关系可以用下面的方式理解adOpenForwardOnly 0默认值只能向前移动RecordCount通常返回-1。adOpenKeyset 1键集游标通常能返回较正确的记录数但受数据源影响。adOpenDynamic 2动态游标可能返回-1也可能返回不准确的记录数取决于数据源。adOpenStatic 3静态游标通常能返回正确的记录数。所以当你在 ASP 里看到RecordCount-1第一步不是反复改 SQL而是检查CursorLocation和CursorType。最直接的改法有两种把服务器游标改成客户端游标也就是在Open之前设置Rs.CursorLocation adUseClient或者把CursorType设为adOpenStatic(3)。如果希望更可靠可以同时使用客户端游标和静态游标。这里还有一个容易踩坑的点adUseClient的值是3adOpenStatic的值也是3但它们属于不同属性含义完全不同。Rs.CursorLocation 3表示游标位置在客户端Rs.Open SqlStr, Conn, 3, 1里的第三个参数3表示静态游标。不要把两者混为一谈。二、TaoToken 前置先把 Codex 的排查通道接上这篇内容的核心不是让 Codex 替你改游标而是让 Codex 帮你对照代码、解释现象、列出修改点。TaoToken 在这里承担的是模型接入层你注册后拿到 API Key把 Codex 的 Base URL 指向 TaoToken就可以在本地项目里让 Codex 读取 ASP 片段并做排障问答。先打开 TaoToken 官网https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentrecordcount_fix完成注册后进入控制台创建 API Key。创建时建议单独给 Codex 用一个 Key后面排查结束后也方便区分和管理。拿到 Key 后不要把它直接写进文章或提交到代码仓库而是放到环境变量里。Codex 需要填写的 Base URL 是https://taotoken.net/api注意这个 API 地址不需要额外加查询参数。TaoToken 只提供 Key 和 Base URL不替代 ADODB 的游标逻辑也不会主动去操作你的 RecordSet。Codex 能帮你做的是读取你提供的 ASP 代码片段解释为什么默认服务器游标返回-1指出CursorLocation应该放在Open之前给出adUseClient和Static(3)的对照写法并提醒你用Recordset.Supports检查当前游标是否支持记录数属性。如果你的项目里已经有很多 ASP 文件建议先把最小复现代码放到单独目录例如recordcount_test.asp再让 Codex 读取这个文件。这样上下文更干净排查结论也更聚焦。三、可复制配置Codex config.toml 与 ASP 复现代码Codex 的配置一般在用户目录下的config.toml中。下面是一份可复制的配置示例把模型提供方指向 TaoToken# ~/.codex/config.toml model gpt-4.1 model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY然后把 API Key 放进环境变量。Linux 或 macOS 可以这样export TAOTOKEN_API_KEYYOUR_API_KEYWindows PowerShell 可以这样$env:TAOTOKEN_API_KEYYOUR_API_KEY如果你使用的是其他 Codex 启动方式只要保持两个关键点不变Base URL 填https://taotoken.net/apiAPI Key 通过环境变量或对应的密钥配置传入。不要把 Key 硬编码到config.toml里。接下来准备一个最小 ASP 复现文件文件名可以叫recordcount_test.asp。代码里故意保留三种情况Conn.Execute、默认Rs.Open、以及修正后的adUseClient Static。% Dim Conn, Rs, SqlStr Set Conn Server.CreateObject(ADODB.Connection) Conn.Open ProviderSQLOLEDB;Data Source你的服务器;Initial Catalog你的库;User ID你的账号;Password你的密码; SqlStr SELECT * FROM 你的表 WHERE 条件 情况一Conn.Execute通常得到只进游标 Set Rs Conn.Execute(SqlStr) Response.Write Conn.Execute RecordCount Rs.RecordCount br Rs.Close Set Rs Nothing 情况二默认服务器游标 ForwardOnly Set Rs Server.CreateObject(ADODB.Recordset) Rs.Open SqlStr, Conn, 0, 1 Response.Write 默认 ForwardOnly RecordCount Rs.RecordCount br Rs.Close Set Rs Nothing 情况三客户端游标 静态游标 Set Rs Server.CreateObject(ADODB.Recordset) Rs.CursorLocation 3 adUseClient Rs.Open SqlStr, Conn, 3, 1 adOpenStatic, adLockReadOnly Response.Write adUseClient Static RecordCount Rs.RecordCount br If Rs.Supports(16384) Then adApproxPosition Response.Write Supports(adApproxPosition)TrueRecordCount 可用br Else Response.Write Supports(adApproxPosition)FalseRecordCount 可能不可用br End If Rs.Close Set Rs Nothing Conn.Close Set Conn Nothing %这段代码的关键不是复制粘贴就能跑而是让 Codex 对照三种情况。第一种和第二种大概率会输出-1第三种在多数数据源和驱动组合下会输出正确记录数。Rs.CursorLocation 3必须在Rs.Open之前设置如果写在Open之后等于没有生效。Rs.Supports(16384)用来测试当前游标是否支持adApproxPosition这个属性与RecordCount的可用性关系密切。adApproxPosition的值是16384也可以写成adApproxPosition常量但 ASP 里如果没引入常量定义直接写数值更省事。四、验证请求让 Codex 解释服务器游标为什么返回 -1配置好 Codex 后在包含recordcount_test.asp的目录里启动 Codex然后输入类似下面的提示读取当前目录的 recordcount_test.asp。 请解释为什么 Conn.Execute 和默认 Rs.Open 的 RecordCount 是 -1。 对照 CursorLocation、CursorType、LockType 给出修改方案。 重点说明 adUseClient 与 adOpenStatic 的区别以及 CursorLocation 必须在 Open 之前设置。 最后给出用 Recordset.Supports(adApproxPosition) 验证的代码。一个符合预期的回答应该包含这些要点第一Conn.Execute返回的 Recordset 往往是只进、只读、服务器端游标。它没有在客户端维护完整结果集所以RecordCount返回-1。这种 Recordset 通常也不适合再去改CursorLocation更推荐改用Server.CreateObject(ADODB.Recordset)后显式Open。第二默认Rs.Open SqlStr, Conn, 0, 1中CursorType0是adOpenForwardOnlyLockType1是adLockReadOnly。只进游标只保证向前遍历不保证行数统计。再加上默认CursorLocationadUseServerRecordCount返回-1是常见行为。第三修正方式一是在Open前设置Rs.CursorLocation 3 adUseClient修正方式二是把游标类型改为静态游标Rs.Open SqlStr, Conn, 3, 1 adOpenStatic, adLockReadOnly如果想更稳妥可以两者同时使用。但要注意客户端游标会把结果集拉到客户端内存记录数很大时会增加内存压力。对于小结果集或确实需要RecordCount的场景这种代价通常可以接受对于大结果集应该重新考虑是否真的需要一次性拿到全部记录数。第四验证时可以加上If Rs.Supports(16384) Then Response.Write 当前游标支持 adApproxPositionRecordCount 可用 Else Response.Write 当前游标不支持 adApproxPositionRecordCount 可能不可用 End If如果Supports(16384)返回False即使你改了CursorLocation或CursorType也要检查数据库驱动是否支持该游标组合。不同数据源、不同 OLE DB 提供程序对游标的支持程度并不完全一致。五、本篇常见错排查CursorLocation、CursorType、RecordCount 还不正常怎么办如果你已经按上面的方式改了RecordCount仍然不是预期值可以按下面顺序排查。第一种常见错CursorLocation写在了Rs.Open后面。ADO 要求游标位置在打开记录集之前确定写在后面不会改变当前 Recordset 的游标位置。正确顺序一定是先设置属性再Open。第二种常见错继续使用Conn.Execute然后试图改Rs.CursorLocation。Conn.Execute返回的记录集通常不是为你后续调整游标而设计的。要精确控制CursorLocation和CursorType就改用Server.CreateObject(ADODB.Recordset)然后显式调用Rs.Open。第三种常见错把adUseClient3和adOpenStatic3搞混。CursorLocation是游标位置CursorType是游标类型。Rs.CursorLocation 3表示客户端游标Rs.Open SqlStr, Conn, 3, 1的第三个参数才是静态游标。两个3出现在不同位置作用不同。第四种常见错只改CursorType不改CursorLocation。某些数据源下服务器端静态游标也能返回记录数但另一些驱动下服务器端游标仍可能不提供RecordCount。如果业务确实依赖记录数建议优先测试adUseClient adOpenStatic组合。第五种常见错忽略LockType的影响。LockType主要影响并发和更新行为一般不直接决定RecordCount但某些锁类型和游标组合可能影响记录集行为。排查时可以用adLockReadOnly(1)做最小化测试。第六种常见错没有用Supports检查。Recordset.Supports(adApproxPosition)可以帮助判断当前游标是否支持近似定位而RecordCount的可用性与该能力相关。如果返回False就不要强行依赖RecordCount可以考虑用SELECT COUNT(*)单独取总数或者在 SQL 层完成分页统计。第七种常见错结果集确实为空。RecordCount-1和RecordCount0不是一回事。0表示没有记录-1表示当前游标不提供记录数。先确认 SQL 本身能返回数据再排查游标。第八种常见错记录集已经关闭或连接已经释放。RecordCount要在Rs.Close之前读取。连接关闭后再访问 Recordset 属性可能得到错误或不可预期的结果。第九种常见错数据库驱动差异。Access、SQL Server、Oracle、MySQL 通过不同 OLE DB 或 ODBC 驱动接入时对客户端游标和静态游标的支持程度不同。Codex 可以帮你列出排查方向但最终要在你的运行环境里用Supports和实际输出确认。如果你把报错信息、ASP 片段、连接字符串中的驱动部分脱敏后交给 Codex它可以更快地对照CursorLocation、CursorType、LockType给出修改建议。注意不要提交真实账号、密码、IP 和业务敏感字段。六、语义一致 CTA继续用 TaoToken 查接入与排障这篇的核心是排障RecordCount-1不是 SQL 没查到数据而是 ADODB.RecordSet 的游标位置和游标类型没有给出记录数。用 Codex 走 TaoToken 通道可以把 ASP 代码片段、现象和游标取值放在一起对照快速得到CursorLocation改adUseClient、CursorType用Static(3)的修改方向再用Recordset.Supports(adApproxPosition)做验证。如果你还没有 Key先去 TaoToken 控制台创建https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentrecordcount_fix接入 Codex 时Base URL 填https://taotoken.net/api具体配置和参数说明可以对照接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentrecordcount_fix如果你后续还要长期在项目里用 Codex 做 ASP 老代码排查、配置核对和接口联调可以再了解 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentrecordcount_fix先把recordcount_test.asp跑一遍确认三种写法的输出差异再让 Codex 对照解释。这样你得到的不只是一个改法而是能复用到其他 ADODB.RecordSet 场景里的游标判断方法。