Professional Web Applications Themes

Why not simply WHILE FETCH_STATUS = 0? - Microsoft SQL / MS SQL Server

It really depends on what type of cursor you use. If you use a static cursor then you can never get anything other than a 0 since all the rows will always be there. If you have a dynamic cursor you could attempt to fetch a row that someone just deleted and it will fail. If your only checking for 0 it will fail and you would most likely stop fetching assuming they are all done. Where as if you checked for more than 0 you can be more flexible. -- Andrew J. Kelly SQL Server MVP "Bob Barrows" <reb_01501> ...

  1. #1

    Default Re: Why not simply WHILE FETCH_STATUS = 0?

    It really depends on what type of cursor you use. If you use a static
    cursor then you can never get anything other than a 0 since all the rows
    will always be there. If you have a dynamic cursor you could attempt to
    fetch a row that someone just deleted and it will fail. If your only
    checking for 0 it will fail and you would most likely stop fetching assuming
    they are all done. Where as if you checked for more than 0 you can be more
    flexible.

    --

    Andrew J. Kelly
    SQL Server MVP


    "Bob Barrows" <reb_01501> wrote in message
    news:ut4$ByyRDHA.2460TK2MSFTNGP10.phx.gbl...
    > SQL 6.5 BOL recommended a two-step process of making sure FETCH NEXT
    > returned results:
    > FETCH NEXT FROM ...
    > WHILE (fetch_status <> -1)
    > BEGIN
    > IF (fetch_status <> -2)
    > etc.
    >
    > The reason it gave never made sense to me: "Because fetch_status will
    > return -2, -1, or 0, all three cases must be tested"
    >
    > The SQL2000 BOL examples more simply say:
    >
    > WHILE fetch_status = 0
    > BEGIN
    > etc.
    >
    > However, the cursor templates in QA revert to the two-step process. I'm
    > confused: why is the 2-step process considered de rigeuer?
    >
    > Bob Barrows
    >
    >
    >

    Andrew J. Kelly Guest

  2. #2

    Default Re: Why not simply WHILE FETCH_STATUS = 0?

    Ah, that makes sense. Many thanks.

    Bob

    Andrew J. Kelly wrote:
    > It really depends on what type of cursor you use. If you use a static
    > cursor then you can never get anything other than a 0 since all the
    > rows will always be there. If you have a dynamic cursor you could
    > attempt to fetch a row that someone just deleted and it will fail.
    > If your only checking for 0 it will fail and you would most likely
    > stop fetching assuming they are all done. Where as if you checked
    > for more than 0 you can be more flexible.
    >
    >
    > "Bob Barrows" <reb_01501> wrote in message
    > news:ut4$ByyRDHA.2460TK2MSFTNGP10.phx.gbl...
    >> SQL 6.5 BOL recommended a two-step process of making sure FETCH NEXT
    >> returned results:
    >> FETCH NEXT FROM ...
    >> WHILE (fetch_status <> -1)
    >> BEGIN
    >> IF (fetch_status <> -2)
    >> etc.
    >>
    >> The reason it gave never made sense to me: "Because fetch_status
    >> will return -2, -1, or 0, all three cases must be tested"
    >>
    >> The SQL2000 BOL examples more simply say:
    >>
    >> WHILE fetch_status = 0
    >> BEGIN
    >> etc.
    >>
    >> However, the cursor templates in QA revert to the two-step process.
    >> I'm confused: why is the 2-step process considered de rigeuer?
    >>
    >> Bob Barrows


    Bob Barrows Guest

  3. #3

    Default Re: Why not simply WHILE FETCH_STATUS = 0?

    Why we use "Fetch_status"
    abdheshtech Guest

Similar Threads

  1. quite simply
    By melaboev in forum Macromedia Exchange Dreamweaver Extensions
    Replies: 0
    Last Post: March 13th, 10:31 AM
  2. Probably Very simply but how?
    By Hong in forum PHP Development
    Replies: 1
    Last Post: September 18th, 06:02 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139