On Adaptive Server Enterprise, a language cursor is declared with the declare cursor statement, opened with an open statement, and fetched from using fetch statements. See the Adaptive Server Enterprise Reference Manual for descriptions of these commands. A Client-Library program can send all of these statements as normal language commands.
Once a language cursor has been declared and opened, each fetch language command returns a set of regular rows (ct_results result_type is CS_ROW_RESULT) and can be handled just like the results of a select command (see “Processing regular row results”). As with any other language command, the results of each command must be processed with ct_results (and ct_fetch, if necessary) before another command can be sent on the connection.
When declared within a language command sent by a client connection, a language cursor has scope limited to that connection. In other words, only language commands sent over the same connection can reference the cursor.
Language cursors provide the following advantage over Client-Library cursors:
On Adaptive Server Enterprise, you can declare a cursor and open inside a Transact-SQL stored procedure. Such a cursor is called a server cursor. Complex tasks that are implemented using a stored procedure and server cursors should perform better than an equivalent implementation that uses Client-Library cursors. The performance difference is mainly due to the fact that the Client-Library cursor requires many network round trips to fetch the cursor rows (and to execute any nested update commands), while the server cursor does not.
Language cursors can be used with an existing client application that handles ad hoc language commands. For example, a user of the Sybase isql client application can use language cursors, even though isql contains no special code to support cursors.
The Adaptive Server Enterprise Reference Manual contains more detailed information on language cursors.
