Using a CURSOR is not normally the best way to process through a set of records. Yet when a seasoned programmer moves to writing TSQL for the first time they frequently look for ways to process a sets of records one row at a time. They do this because they are not used to thinking about processing records as a set. In order to process through a TSQL record set a row at a time you can use a cursor. A cursor is a record set that is defined with the DECLARE CURSOR statement. Cursors can be defined as either read-only or updatable. In this article I will introduce you to using cursors to do record level processing one row at a time.
Exploring some differences between using cursors, local fast forward cursors and using set logic.
Cursors are considered by many to be the bane of good T-SQL. What are the best ways to avoid iterative T-SQL and to write queries that look and perform beautifully? In the next part of an ongoing series, we look at ways to efficiently retrieve recently modified data.
Cursors are considered by many to be the bane of good T-SQL. What are the best ways to avoid iterative T-SQL and to write queries that look and perform beautifully? This first part in an ongoing series of cursor-killing handles inter-row analysis.
In this article, we provide a simple way to get a comma delimited list from a table of entries without having to use a CURSOR or a WHILE loop to read through the table.
Cursors provide a means of processing through a set of records row-by-row. However, many companies have a policy against using cursors in their SQL Server standards. This article examines the problem with cursors and alternatives to using them.