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. Other Discussions
  3. The Weird and The Wonderful
  4. A whole day wasted on one stored procedure

A whole day wasted on one stored procedure

Scheduled Pinned Locked Moved The Weird and The Wonderful
helpdatabasesharepointtutorialquestion
5 Posts 4 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.
  • C Offline
    C Offline
    ChrisC ncmail
    wrote on last edited by
    #1

    Half a day to find the sp causing the problem... another half to fix it and send emails out about it. The first problem is that the original programmer (not here) said that the problem didn't happen. This was "a while back" and eventually the users found a way prove that the problem does exist. So I find the offending sp and it is: almost 200 lines long, creats a temp table as it's first action, contains two cursors, and the cursor for each fetch had an "IF NOT EXISTS(...". Correct me if I'm wrong: using the EXISTS is a big no-no, right? Shouldn't you just do an extra left join (if necessary) and use that field instead of the EXISTS? In fairness to the original coder, I am not sure how this could have been done without a cursor. (I know it can... I'm just saying that generally if I stare at something with a cursor I quickly see how to do it without one - but that didn't happen this time) Seven hours I spent on this today, plus having our contractor in my cube for about half a day, plus the meeting with my boss + her boss, plus what I spent on this last week. Ironically, the original programmer was "literally correct" the problem (as stated by the user) was not a bug, though the application *was* certainly wrong. [sigh] Since I'm mostly getting this off my chest I put it in coding horrors instead of the db forum.

    J D 2 Replies Last reply
    0
    • C ChrisC ncmail

      Half a day to find the sp causing the problem... another half to fix it and send emails out about it. The first problem is that the original programmer (not here) said that the problem didn't happen. This was "a while back" and eventually the users found a way prove that the problem does exist. So I find the offending sp and it is: almost 200 lines long, creats a temp table as it's first action, contains two cursors, and the cursor for each fetch had an "IF NOT EXISTS(...". Correct me if I'm wrong: using the EXISTS is a big no-no, right? Shouldn't you just do an extra left join (if necessary) and use that field instead of the EXISTS? In fairness to the original coder, I am not sure how this could have been done without a cursor. (I know it can... I'm just saying that generally if I stare at something with a cursor I quickly see how to do it without one - but that didn't happen this time) Seven hours I spent on this today, plus having our contractor in my cube for about half a day, plus the meeting with my boss + her boss, plus what I spent on this last week. Ironically, the original programmer was "literally correct" the problem (as stated by the user) was not a bug, though the application *was* certainly wrong. [sigh] Since I'm mostly getting this off my chest I put it in coding horrors instead of the db forum.

      J Offline
      J Offline
      J4amieC
      wrote on last edited by
      #2

      ChrisC(@ncmail) wrote:

      Correct me if I'm wrong: using the EXISTS is a big no-no, right? Shouldn't you just do an extra left join (if necessary) and use that field instead of the EXISTS

      You're wrong. try it.

      1 Reply Last reply
      0
      • C ChrisC ncmail

        Half a day to find the sp causing the problem... another half to fix it and send emails out about it. The first problem is that the original programmer (not here) said that the problem didn't happen. This was "a while back" and eventually the users found a way prove that the problem does exist. So I find the offending sp and it is: almost 200 lines long, creats a temp table as it's first action, contains two cursors, and the cursor for each fetch had an "IF NOT EXISTS(...". Correct me if I'm wrong: using the EXISTS is a big no-no, right? Shouldn't you just do an extra left join (if necessary) and use that field instead of the EXISTS? In fairness to the original coder, I am not sure how this could have been done without a cursor. (I know it can... I'm just saying that generally if I stare at something with a cursor I quickly see how to do it without one - but that didn't happen this time) Seven hours I spent on this today, plus having our contractor in my cube for about half a day, plus the meeting with my boss + her boss, plus what I spent on this last week. Ironically, the original programmer was "literally correct" the problem (as stated by the user) was not a bug, though the application *was* certainly wrong. [sigh] Since I'm mostly getting this off my chest I put it in coding horrors instead of the db forum.

        D Offline
        D Offline
        David Skelly
        wrote on last edited by
        #3

        ChrisC(@ncmail) wrote:

        Correct me if I'm wrong: using the EXISTS is a big no-no, right? Shouldn't you just do an extra left join (if necessary) and use that field instead of the EXISTS?

        There are a couple of good discussions about this here: http://weblogs.sqlteam.com/mladenp/archive/2007/05/18/60210.aspx[^] http://drsql.spaces.live.com/blog/cns!80677FB08B3162E4!766.entry[^]

        C 1 Reply Last reply
        0
        • D David Skelly

          ChrisC(@ncmail) wrote:

          Correct me if I'm wrong: using the EXISTS is a big no-no, right? Shouldn't you just do an extra left join (if necessary) and use that field instead of the EXISTS?

          There are a couple of good discussions about this here: http://weblogs.sqlteam.com/mladenp/archive/2007/05/18/60210.aspx[^] http://drsql.spaces.live.com/blog/cns!80677FB08B3162E4!766.entry[^]

          C Offline
          C Offline
          ChrisC ncmail
          wrote on last edited by
          #4

          Thanks! :thumbsup: http://drsql.spaces.live.com/blog/cns!80677FB08B3162E4!766.entry[^] My tendency is to use a join, so I found this comment especially useful: [quote] So in conclusion, the point of this post is to avoid using joins to try to compare two sets, since this is not its function. In the end the join method doesn't seem clear as to what you are asking. I only touched on performance, but the join will often peform worse than the using in or exists, simply because the work involved to do the join is greater. [/quote] [sigh] live and learn

          P 1 Reply Last reply
          0
          • C ChrisC ncmail

            Thanks! :thumbsup: http://drsql.spaces.live.com/blog/cns!80677FB08B3162E4!766.entry[^] My tendency is to use a join, so I found this comment especially useful: [quote] So in conclusion, the point of this post is to avoid using joins to try to compare two sets, since this is not its function. In the end the join method doesn't seem clear as to what you are asking. I only touched on performance, but the join will often peform worse than the using in or exists, simply because the work involved to do the join is greater. [/quote] [sigh] live and learn

            P Offline
            P Offline
            PIEBALDconsult
            wrote on last edited by
            #5

            ChrisC(@ncmail) wrote:

            will often peform worse

            Test it.

            ChrisC(@ncmail) wrote:

            the work involved to do the join is greater

            Though that work may be beneficial in some cases.

            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