The static cursor always displays the result set as it was when the cursor was first opened. Depending on implementation, static cursors are either read-only or read/write and provide forward and backward scrolling. The static cursor does not usually detect changes made to the membership, order, or values of the result set after the cursor is opened. Static cursors may detect their own updates, deletes, and inserts, although they are not required to do so.
Static cursors never detect other updates, deletes, and inserts. For example, suppose a static cursor fetches a row and another application and then updates that row. If the application refetches the row from the static cursor, the values it sees are unchanged, despite the changes made by the other application.
Static cursors are commonly implemented by locking the table rows that are in the result set or making a copy (snapshot) of the result set. While locking table rows is easy to do, it has the drawback of significantly reducing concurrency. Making a copy allows greater concurrency and allows the cursor to keep track of its own updates, deletes, and inserts by modifying the copy. However, a copy requires extra resources and can diverge from the underlying data as that data is changed by others.
For More Information For more information on concurrency problems and how they are handled with row locking options, see Managing Concurrency with Cursor Locks.
If your application does not need to detect data changes, the static cursor is the best choice.