Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. Database & SysAdmin
  3. Database
  4. SQL Server Cursor - Quick Question

SQL Server Cursor - Quick Question

Scheduled Pinned Locked Moved Database
databasequestionsql-servercomsysadmin
5 Posts 3 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • J Offline
    J Offline
    Jawz X
    wrote on last edited by
    #1

    I have a question SQL Server cursor question I have a table, “clients”. I want to create a cursor to select and iterate through each client in the database. Obviously, that will lock the “clients” table. Fine. But if I involve another table to do a filter (in the where clause, to reduce the result set) does that lock both tables and just the “Client” table? Thanks in advance, Frank www.TheOpenSourceU.com

    J E 2 Replies Last reply
    0
    • J Jawz X

      I have a question SQL Server cursor question I have a table, “clients”. I want to create a cursor to select and iterate through each client in the database. Obviously, that will lock the “clients” table. Fine. But if I involve another table to do a filter (in the where clause, to reduce the result set) does that lock both tables and just the “Client” table? Thanks in advance, Frank www.TheOpenSourceU.com

      J Offline
      J Offline
      Jawz X
      wrote on last edited by
      #2

      Also, it is important to note that the table i'd be using is a constantly used table (it touches almost every thing) Thanks again, Frank www.TheOpenSourceU.com

      1 Reply Last reply
      0
      • J Jawz X

        I have a question SQL Server cursor question I have a table, “clients”. I want to create a cursor to select and iterate through each client in the database. Obviously, that will lock the “clients” table. Fine. But if I involve another table to do a filter (in the where clause, to reduce the result set) does that lock both tables and just the “Client” table? Thanks in advance, Frank www.TheOpenSourceU.com

        E Offline
        E Offline
        Eric Dahlvang
        wrote on last edited by
        #3

        Jawz-X wrote:

        I want to create a cursor to select and iterate through each client in the database. Obviously, that will lock the “clients” table.

        It will not obviously lock the clients table. SQL Server Books Online: Cursor Transaction Isolation Levels The transaction locking behavior of a specific cursor is determined by combining the locking behaviors of the cursor concurrency setting, any locking hints specified in the cursor SELECT, and transaction isolation level options. Microsoft® SQL Server™ 2000 supports these cursor transaction isolation levels: Read Committed SQL Server acquires a share lock while reading a row into a cursor but frees the lock immediately after reading the row. Because shared lock requests are blocked by an exclusive lock, a cursor is prevented from reading a row that another task has updated but not yet committed. Read committed is the default isolation level setting for both SQL Server and ODBC. Read Uncommitted SQL Server requests no locks while reading a row into a cursor and honors no exclusive locks. Cursors can be populated with values that have already been updated but not yet committed. The user is bypassing all of the locking transaction control mechanisms in SQL Server. Repeatable Read or Serializable SQL Server requests a shared lock on each row as it is read into the cursor as in READ COMMITTED, but if the cursor is opened within a transaction, the shared locks are held until the end of the transaction instead of being freed after the row is read. This has the same effect as specifying HOLDLOCK on a SELECT statement. ---------- Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them. - Laurence J. Peters

        J 1 Reply Last reply
        0
        • E Eric Dahlvang

          Jawz-X wrote:

          I want to create a cursor to select and iterate through each client in the database. Obviously, that will lock the “clients” table.

          It will not obviously lock the clients table. SQL Server Books Online: Cursor Transaction Isolation Levels The transaction locking behavior of a specific cursor is determined by combining the locking behaviors of the cursor concurrency setting, any locking hints specified in the cursor SELECT, and transaction isolation level options. Microsoft® SQL Server™ 2000 supports these cursor transaction isolation levels: Read Committed SQL Server acquires a share lock while reading a row into a cursor but frees the lock immediately after reading the row. Because shared lock requests are blocked by an exclusive lock, a cursor is prevented from reading a row that another task has updated but not yet committed. Read committed is the default isolation level setting for both SQL Server and ODBC. Read Uncommitted SQL Server requests no locks while reading a row into a cursor and honors no exclusive locks. Cursors can be populated with values that have already been updated but not yet committed. The user is bypassing all of the locking transaction control mechanisms in SQL Server. Repeatable Read or Serializable SQL Server requests a shared lock on each row as it is read into the cursor as in READ COMMITTED, but if the cursor is opened within a transaction, the shared locks are held until the end of the transaction instead of being freed after the row is read. This has the same effect as specifying HOLDLOCK on a SELECT statement. ---------- Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them. - Laurence J. Peters

          J Offline
          J Offline
          Jawz X
          wrote on last edited by
          #4

          Thank you for that information. So, the answer to my question is that, in fact, neither table will be locked. So, I should probably know this, but please enlighten me and save me some research (I don't use cursors very often, I think I did one once). But why then are cursors to be considered a last resort? Is it simply the amount of resources that they use on the DBMS? Thank you, Frank www.TheOpenSourceU.com P.S. I like your quote.

          C 1 Reply Last reply
          0
          • J Jawz X

            Thank you for that information. So, the answer to my question is that, in fact, neither table will be locked. So, I should probably know this, but please enlighten me and save me some research (I don't use cursors very often, I think I did one once). But why then are cursors to be considered a last resort? Is it simply the amount of resources that they use on the DBMS? Thank you, Frank www.TheOpenSourceU.com P.S. I like your quote.

            C Offline
            C Offline
            Colin Angus Mackay
            wrote on last edited by
            #5

            Jawz-X wrote:

            But why then are cursors to be considered a last resort?

            Because they are increadibly slow. I once saw a question on this forum complaining that the code was taking too long (it was using cursors). I suggested a better query to use without cursors and the operation took around one second to complete. Some things cannot be solved without cursors which is why they exist. But oftentimes the code can be re-written without cursors.


            "On two occasions, I have been asked [by members of Parliament], 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able to rightly apprehend the kind of confusion of ideas that could provoke such a question." --Charles Babbage (1791-1871) My: Website | Blog

            1 Reply Last reply
            0
            Reply
            • Reply as topic
            Log in to reply
            • Oldest to Newest
            • Newest to Oldest
            • Most Votes


            • Login

            • Don't have an account? Register

            • Login or register to search.
            • First post
              Last post
            0
            • Categories
            • Recent
            • Tags
            • Popular
            • World
            • Users
            • Groups