When your boss edits your SQL...



  • Revisiting a screen for the first time that day, I find that one of my dropdown menus is not populating. Funny, it worked yesterday. Delving into the code, I find my stored procedure is returning zero rows. Delving into the query analyzer, I find my stored procedure has been alerted:

    SELECT distinct oo.child_office_code,
        bo.office_name, bo.office_abbreviation,
        su.user_code, su.first_name, su.last_name,
        su.role_code, sr.role_name
      FROM sec_users su
        INNER JOIN sec_users_office suo ON
          su.user_code = suo.user_code
        INNER JOIN office_owner oo ON
          suo.office_code = oo.office_code
        INNER JOIN sec_roles sr ON
          su.role_code = sr.role_code
        INNER JOIN base_office bo ON
          oo.child_office_code = bo.office_code
      WHERE su.user_code = @user_code
        -- modified [dave s, 17-Jan-2007]:
        and suo.office_code not in (select child_office_code from office_owner)
        -- end modification


    The edit looks ok, unless you know that every office is its own parent and child, so this procedure always returns no rows. Fortunately, I had already written a better version of this procedure using a view, so no code was lost.



  • Considering he documented the change and it looks like he simply added a check, he did ok.  This is much better then him making the change and claiming he never touched it (except for one little piece that shouldn't matter).

    Granted he obviously didn't test it.  Just one more reason for change control in SQL.



  • True, it could've been a whole lot worse. He did just add a check (that always returns false), and he did claim responsibility.

    Still, it was annoying when a client testing the software called me, asking why he didn't have access to any offices.



  • @Edgesmash said:

    Still, it was annoying when a client testing the software called me, asking why he didn't have access to any offices.

    And I wondered why the new managers here wanted to set up four separate environments (Dev, test, qa, production). It's because they reserve the right to screw up the Dev stuff at any time without telling me...
     



  • The edit looks ok, unless you know that every office is its own parent and child, so this procedure always returns no rows.

    Um, isn't that the WTF? Altho it could be the beginning of a new class of family tree jokes:

    Ha-ha, your family tree is a straight line!

    Oh yeah? Well your family tree is a mobius strip!



  • We call these "mistakes."



  • @Pap said:

    We call these "mistakes."

     

    Well apparently, the submitter never ever makes any of those. I'm sure he's never added/modified code that broke something. Someday, I hope to reach that kind of coding excellence. For now I am relegated to admitting that I make mistakes just like all of my colleagues do. Oh, the humanity!

     



  • @Pap said:

    We call these "mistakes."

    I call them WTF's.



  • @unklegwar said:

    @Pap said:

    We call these "mistakes."

    Well apparently, the submitter never ever makes any of those. I'm sure he's never added/modified code that broke something. Someday, I hope to reach that kind of coding excellence. For now I am relegated to admitting that I make mistakes just like all of my colleagues do. Oh, the humanity!



    Of course I make mistakes. However, the bare minimum of testing I do after I make a change is open the application and go to the change. The rest of this altered procedure is to make a screen load with no data.

    @reverendryan said:
    The edit looks ok, unless you know that every office is its own parent and child, so this procedure always returns no rows.

    Um, isn't that the WTF? Altho it could be the beginning of a new class of family tree jokes:

    Ha-ha, your family tree is a straight line!

    Oh yeah? Well your family tree is a mobius strip!



    Some other code relies on offices being their own parents. Don't get me started on the overall design of the project...



  • @unklegwar said:

    @Pap said:

    We call these "mistakes."

    Well apparently, the submitter never ever makes any of those. I'm sure he's never added/modified code that broke something. Someday, I hope to reach that kind of coding excellence. For now I am relegated to admitting that I make mistakes just like all of my colleagues do. Oh, the humanity!

    I make an amazing number of mistakes. However, I usually catch most of those by testing before they go live to customers. Even when they do go live and other people can see them, it's almost always in an environment that isn't production (and it's reasonable to assume this may have been a prod system as it was the client that let them know)


Log in to reply