简述asp页面内部访问数据库的过程

一个ASP页面访问数据库，简述据库本质上就是面内四步走：建立连接、发送SQL命令、部访处理返回结果、问数关闭连接。简述据库这套流程在今天的面内各种ORM框架里被层层封装，但在ASP的部访老代码里，每一步都得你自己动手。问数

先看最核心的简述据库一段代码，几乎所有ASP程序员的面内入门记忆里都有它：

Dim conn, rs Set conn = Server.CreateObject("ADODB.Connection") conn.Open "Provider=SQLOLEDB;Data Source=localhost;Initial Catalog=Northwind;User ID=sa;Password=123" Set rs = Server.CreateObject("ADODB.Recordset") rs.Open "SELECT * FROM Products", conn 

这里有个细节很多人容易忽略——连接字符串是纯文本，一旦写死在代码里，部访数据库密码就裸奔在服务器上。问数当年我见过某公司的简述据库ASP站点，连接字符串里挂着sa账户的面内明文密码，跟今天有人把API密钥传GitHub是部访一个性质。但ASP时代的开发者没得选，加密组件要额外装，配置IIS权限又麻烦，于是大量站点就这么敞着。

接着是发送命令。上面例子用的是Recordset直接打开SQL，其实还有另一种写法：

Dim cmd Set cmd = Server.CreateObject("ADODB.Command") cmd.ActiveConnection = conn cmd.CommandText = "UPDATE Products SET UnitPrice = UnitPrice * 1.1 WHERE CategoryID = 1" cmd.Execute 

用Command对象的好处是能传参数，减少SQL注入风险。但讽刺的是，我翻过不少老项目，大家图省事，全用字符串拼接SQL。你问他们不怕注入吗？答曰：内网系统，没人攻击。直到有一天某个外包项目被脱裤，才慌慌张张把所有查询改成参数化——但那时候ASP已经快进坟墓了。

数据取回来后，循环输出是家常便饭。典型写法是：

Do While Not rs.EOF Response.Write "<li>" & rs("ProductName") & " - $" & rs("UnitPrice") & "</li>" rs.MoveNext Loop 

这里有个性能陷阱。很多人习惯在循环里直接Response.Write，如果数据量上千，页面会明显卡顿。正确做法是先拼字符串再一次性输出，或者用Response.Buffer。但当时没几个人在意，反正访问量也不高。我见过一个后台管理页面，查两万条记录，循环里还嵌套了三个子查询，每次打开要等十几秒。后来改成分页查询，体验立刻起飞——所以说，ASP不是不能优化，是懒人太多。

最后一步，关闭对象。标准姿势是：

rs.Close Set rs = Nothing conn.Close Set conn = Nothing 

这段代码必须放在finally块或者页面末尾。但ASP没有try-catch（VBScript的On Error Resume Next又太粗糙），所以经常出现异常后连接没释放的情况。数据库连接池被占满，后续请求全部超时——这种故障在当年的论坛里隔三差五有人问。

还有个隐藏细节：页面执行完，如果忘了关闭Recordset，ASP会在页面结束时自动清理。但这依赖IIS的回收机制，不稳定。我自己就踩过坑——一个定时任务页面，每次跑完不关连接，跑了一周后数据库报“连接数达到上限”，重启IIS才好。

说到底，ASP访问数据库的过程并不复杂，难的是在缺乏框架和规范的环境里，保证每个连接都能善始善终。后来ASP.NET带着using语句和连接池管理出现时，老ASP程序员长舒一口气——终于不用手动关对象了。但那段裸写SQL、手动开连接的日子，确实也练出了一批对底层机制了如指掌的人。