一个只向前的快速游标在服务器上比常规游标更快，它让您指定两个附加选项。一个称为自动取数，另一个称为自动关闭。自动取数将返回第一个行集合，作为打开的响应消息的一部分。自动关闭在读完最后一行后自动关闭游标。因为它是只向前的和只读的，所以不能回滚。SQL Server 只传回一个带有说明游标已关闭的最后数据集的消息。如果您正在使用只向前的快速游标，则在行数少的消息里，您可向下与同一往返行程通信。如果您有很多行，则您至少还要对每一行块支付附加开销。如果您使用只向前的快速游标，那么游标处理会更加接近默认的结果集。
SQLExecDirect 模型流程如图 4 所示。
图 4. 客户机/服务器交互
准备/执行模型
除了执行直接模型（在 ODBC 中用 SQLExecDirect 调用）外，在 ODBC 和 OLE-DB 中，还有一种执行模型，称为准备/执行模型。定义要执行的 SQL，是作为一个独立于实际执行 SQL 的步骤来完成的。以下是 ODBC 中的一个例子：
SQLPrepare(hstmt, "SELECT * FROM parts where partid = ?", SQL_NTS)
SQLExecute(hstmt)
在 SQL Server 7.0 版本之前，准备/执行从来都不是 SQL Server 的本机模式。如今在 7.0 版本中，有两个提供本机接口的虚拟系统存储过程。对于准备调用，我们要再次研究游标的类型，然后调用 sp_prepare 或 sp_cursorprepare。这些过程会完成 SQL 或存储过程的编译，但不会实际执行计划。相反，虚拟系统存储过程只是返回该计划的句柄。现在，应用程序可以反复地执行 SQL 了，例如传入不同的参数值，而不需要重新编译。
在 SQL Server 6.5 中，由于没有本机接口，需要模拟准备和执行两个阶段。可以通过下面的两种方法做到这一点。在第一种方法中，不会真正出现准备阶段。只有执行部分返回元数据（有一些选项可以做到这一点），所以 SQL Server 可以把结果的格式描述返回给应用程序。在第二种方法中，SQL Server 实际上创建一个特定存储过程，这个过程是单个用户私用的，不能共享计划。这第二种方法可能会占满 tempdb 数据库的空间，因此大多数应用程序开发人员都通过 ODBC 配置对话框中的复选框，关闭此选项，以使用第二种方法。
在 SQL Server 7.0 中，准备/执行方法是 SQL Server 的本机功能。准备好 SQL 语句之后，才会执行它。至于默认的结果集，应用程序只需要调用 sp_execute，提供准备操作生成的句柄，语句就会被执行。对于游标，与其他游标处理过程看起来很相似，事实上，它也具有相同的特性，包括如果游标是快速只前向型，还可以使用 autofetch 和 toclose。
准备/执行操作的流程如图 5 所示。
图 5. 准备/执行模型
调用存储过程
存储过程一般是从 ODBC 和 OLE-DB，通过发送 SQL 语句给使用 ODBC 标准 CALL 语法调用过程的 SQL Server 来调用。其应类似于以下语句：
SQLExecDirect(hstm, "{call addorder(?)}", SQL_NTS)
对于默认结果集，这是一个简单的流，因为这正是 RPC 消息原本要处理的对象。客户机向服务器发送 RPC 消息，并获取来自存储过程的处理结果。如果是游标，则情况稍微复杂一些，客户机需要调用 Sp_cursoropen，就像其他游标一样。Sp_cursoropen 含有内部逻辑，检测该存储过程是否只包含一条 SELECT 语句。如果是，则对该 SELECT 语句打开一个游标。如果该存储过程中不是一条 SELECT 语句，则客户机会得到一个指示，说明“我们为您打开结果集，但是我们将以流水的方式返回数据流，您可以把这个数据流提供给用户”。
存储过程执行流程如图 6 所示。
图 6. 调用存储过程
SQL Manager
前面已经提到过的 SQL Manager 驱动很多服务器处理过程，它实际上是服务器的心脏。SQL Manager 处理所有调用存储过程的请求，管理过程缓存，拥有虚拟系统存储过程，在稍后要介绍的特定查询的自动参数化过程中也要涉及。如果您有与本文类似的描述 SQL 6.5 或更老版本的文章，则不会读到有关 SQL 管理器的讨论，然而，您会读到一些完成 SQL 管理器工作的一些不同的组件。但是在 SQL Server 7.0 中，这些组件被统一为 SQL 管理器，通过系统驱动查询语句的处理。
在一般情况下，当要求 SQL 管理器为您做某些工作时，通过 RPC 消息调用 SQL 管理器。但是，当通过 SQL 消息发送 SQL 语句并进入引擎编译时，也会用到 SQL 管理器。当存储过程或批处理程序包含 EXEC 语句时，也会调用 SQL 管理器，因为 EXEC 实际上就是调用 SQL 管理器。如果该 SQL 语句传送了下面就要讨论的一个自动参数化模板，则需要调用 SQL 管理器对该查询进行参数化处理。当特定查询语句需要装入缓存时，也要调用 SQL 管理器。
编译与执行
现在讨论在 SQL Server 中编译和执行的一般流程。需要注意的是编译和执行在 SQL Server 内部是两个不同的阶段。SQL Server 编译查询语句和执行该语句之间的间隔时间可能非常短，只有几个毫秒，也可能是几秒钟、几分钟、几小时甚至几天。在编译过程中（这个过程包括优化），我们必须区分什么样的知识可以用于编译。并不是所有对编译有用的知识对执行也起作用。您必须把编译和执行理解为两个不同的活动，即使您发送并立即执行的是特定 SQL 查询语句。
当 SQL Server 可以开始处理查询语句时，SQL Manager 要在缓存内进行查找，如果没有找到该语句，则必须编译该语句。编译处理要完成以下几件工作。首先，要进行分析和正常化。分析就是剖析该 SQL 语句，将其转换成更适合计算机处理的数据结构。分析还要验证语法的正确性。分析不进行表名和列名合法性等检查，这些工作在正常化阶段完成。正常化主要是解析 SQL 语句中引用的对象，转换成实际的数据库对象，检查请求的语义是否有意义。例如，试图执行一个表，这在语义上就是错误的。
下一步是编译 Transact-SQL 代码。Transact-SQL 和 SQL 本身都让人有点儿困惑，Microsoft 的开发人员也像别人一样经常互换两个词。但是，这两者之间还是有重要差别的。SQL 包括所有 DML 语句：INSERT、UPDATE、DELETE 和 SELECT。SQL Server 还有一种包括这些 DML 语句的语言，称为 Transact-SQL，也就是 TSQL。TSQL 提供过程结构：IF 语句、WHILE 语句、局部变量声明等。服务器内部对 SQL 和 TSQL 的处理方法完全不同。TSQL 的过程逻辑要由知道如何进行过程化处理的引擎来编译。
文章整理：西部数码--专业提供域名注册、虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!
