因为游标的缘故，你或许打算熟悉两种创建recordset的方法。直接执行查询节省了键入字符所消耗的时间，但那样的话你就得采用默认的游标了，这样有可能遭遇经常不能正常运行的毛病。不管你具体采用哪种办法，两者之间的最大的差别也不外乎代码精练与否。在不考虑你取得什么字段、你的标准是什么的前提下，也不管你如何存储数据，采用SQL式的recordset 在体积上会比ASP上打开的标准recordset 要小得多，更别提操作起来的简易性了。毕竟，通过过滤数据，你消除了耗费时间的if-then 测试和可能用到的循环。
编写测试用SQL
这里有个技巧，许多专业ASP程序员习惯在测试网页的时候“编写”自己的SQL语句。这样做可以帮助你调试代码，因为你可以从中看到传递给服务器执行的字符串。而你要做的无非是增加Response.WriteyourVariable 在屏幕上显示有关信息。在你把和SQL有关的问题提交给ASP讨论组的时候你就应该附上这些信息。
当你的查询相对简单的时候，每次从头开始创建SQL语句也不费什么工夫，不过，复杂的查询就不同了，每次都从头来会产生很多开发错误。因此，一旦让SQL顺利地运行起来，你最好把它们存起来，在需要时再调用它们。这样，哪怕是一个简单查询你都能随时用上存储的查询语句了。
假设你每周都要给团队做一次报告，指出目前存在的业务支持问题，这些数据需要从你的数据库中选取，而且要按照日期选择记录，同时根据你所在团队所采用的支持问题的类别排序。一旦你设计了这一查询，你何必以后每周都重新编写一次呢？不要在你的HTML页面上创建查询，你应该用你的数据库工具创建查询并且保存它。
然后你可以采用ActiveCommand 属性把查询插入到你的ASP网页。头一两回你可能会觉得没啥意思，其实也就几行代码而已：
Set objSQ = Server.CreateObject ("ADODB.Command")
objSQ.ActiveConnection = "databaseName"
objSQ.CommandText = "storedQueryName"
objSQ.CommandType = adCmdStoredProc
set objRec = objSQ.Execute
注意，采用adCmdStoredProc 表示你已经在页面上包含了adovbs.inc 文件。该文件定义了你可以按照名字而非数字进行访问的Access常数。只需要在页面上包含该文件即可（<!--#INCLUDE -->），然后你就可以用adCmdStoredProc 这类名字了。这样，将来你再看到的时候更容易理解以上被存储的查询到底是个什么意思。