Skip to content

Enhance documentation on FAST_FORWARD cursor behavior #10369

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
HugoKornelis wants to merge 2 commits into
base: live
Choose a base branch
from
Open

Enhance documentation on FAST_FORWARD cursor behavior #10369

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
a35f004
Enhance documentation on FAST_FORWARD cursor behavior
HugoKornelis Aug 3, 2026
47a0b7a
Apply suggestion from @rwestMSFT
rwestMSFT Aug 10, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions docs/t-sql/language-elements/declare-cursor-transact-sql.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -142,6 +142,10 @@ Specifies a `FORWARD_ONLY`, `READ_ONLY` cursor with performance optimizations en
> [!NOTE]
> Both `FAST_FORWARD` and `FORWARD_ONLY` can be used in the same `DECLARE CURSOR` statement.

A `FAST_FORWARD` cursor can either behave as a `STATIC` cursor or as a 'DYNAMIC' cursor. This choice is made at run time, depending on estimated costs, and the choice can change between executions. Since this choice affects whether concurrent modifications are visible to the cursor or not, such a run time change might impact your results. If your application requires that concurrent updates are visible, use a `DYNAMIC` or `KEYSET` cursor instead. If your application requires that concurrent updates are not visible, use a `STATIC` cursor instead.

@rwestMSFT Randolph West MSFT (rwestMSFT) Aug 11, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
A `FAST_FORWARD` cursor can either behave as a `STATIC` cursor or as a 'DYNAMIC' cursor. This choice is made at run time, depending on estimated costs, and the choice can change between executions. Since this choice affects whether concurrent modifications are visible to the cursor or not, such a run time change might impact your results. If your application requires that concurrent updates are visible, use a `DYNAMIC` or `KEYSET` cursor instead. If your application requires that concurrent updates are not visible, use a `STATIC` cursor instead.
A `FAST_FORWARD` cursor can operate as a `STATIC` cursor or a `DYNAMIC` cursor, depending on the calculated query cost at run time. For this reason, the query optimizer might select a different type each time the query runs. If your application requires that concurrent updates are visible, use a `DYNAMIC` or `KEYSET` cursor. Otherwise, use a `STATIC` cursor.


For more information, see [Understanding SQL Server Fast_Forward Server Cursors](https://techcommunity.microsoft.com/blog/sqlserver/understanding-sql-server-fast-forward-server-cursors/383556).

#### READ_ONLY

Prevents updates made through this cursor. The cursor can't be referenced in a `WHERE CURRENT OF` clause in an `UPDATE` or `DELETE` statement. This option overrides the default capability of a cursor to be updated.
Expand Down