Cursors facilitate processing in conjunction with the traversal, such as retrieval, addition and removal of database records.
Not all application bindings for relational database systems adhere to that standard, and some (such as CLI or JDBC) use a different interface.
Applications position cursors on a specific row in the result set with the FETCH statement.
A program may position a scrollable cursor anywhere in the result set using the FETCH SQL statement.
Scrollable cursors can potentially access the same row in the result set multiple times.
Thus, data modifications (insert, update, delete operations) from other transactions could affect the result set.
(Some DBMS deviate from this standard behavior and also keep holdable cursors open over ROLLBACK.)
Cursors can not only be used to fetch data from the DBMS into an application but also to identify a row in a table to be updated or deleted.
Otherwise, the DBMS would not know how to apply the data changes to the underlying tables referred to in the cursor.
This uses much more network bandwidth than would ordinarily be needed for the execution of a single SQL statement like DELETE.
Repeated network round trips can severely reduce the speed of the operation using the cursor.
Cursors allocate resources on the server, such as locks, packages, processes, and temporary storage.
For example, Microsoft SQL Server implements cursors by creating a temporary table and populating it with the query's result set.