| title | Using Server Cursors | ||||
|---|---|---|---|---|---|
| description | Using Server Cursors | ||||
| author | markingmyname | ||||
| ms.author | maghan | ||||
| ms.date | 03/14/2017 | ||||
| ms.service | sql | ||||
| ms.subservice | native-client | ||||
| ms.topic | reference | ||||
| helpviewer_keywords |
|
[!INCLUDE SQL Server]
If an ODBC application sets any of the ODBC cursor attributes to anything other than the defaults, the [!INCLUDEssNoVersion] Native Client ODBC driver requests the server to implement an API server cursor of the same type. Using API server cursors frees memory on the client and can significantly reduce network traffic between the client and server.
A potential drawback of API server cursors is that they currently do not support all SQL statements. API server cursors cannot be used to execute:
-
Batches or stored procedures that return multiple result sets.
-
SELECT statements that contain COMPUTE, COMPUTE BY, FOR BROWSE, or INTO clauses.
-
An EXECUTE statement referencing a remote stored procedure.
When connected to an instance of [!INCLUDEssNoVersion], executing a statement with these characteristics using a server cursor causes the cursor being converted to a default result set. When connected to earlier versions of [!INCLUDEssNoVersion], it causes an error.