• lm_hamilton (10/8/2012)


    Thanks for the script, that will go a long way to speed up finding issues to evaluate for fixing.

    Also, thanks for the concern to make sure I am not clueless when it comes to fixing data. I don't know how the programming language that is used allows things like this to happen, but an old version of the programming language would let it write data when that meant duplicate keys. When we upgraded to a newer version of the programming language, we discovered that we had been exploiting a bug as a feature for the life of the program to that point. That made it a fun job in support to explain that one to clients. So while the database __should__ stop such behavior, there is something about this programming language that did things like this. Thankfully, I think that is in the past. However, there are still bits of data that need cleanup.

    ~ Larry

    You're welcome for the script. It was relatively close to something I had at hand so I was happy to modify it to suit your purposes.

    I disagree with your statement "I don't know how the programming language that is used allows things like this to happen" in that you seem to be blaming te programming language when we all know that computers (and programming languages) only do what they are told to do. The fault of this lies entirely with the developers that misuse it, especially that part about the code relying on an inherent bug in the language. None of these would be easy to spot during a development process without some kind of automated tools.

    I'm working on developing a set of those (this post gave me an idea for one) and it is from there that I was able to extract the script that I supplied you.


    My mantra: No loops! No CURSORs! No RBAR! Hoo-uh![/I]

    My thought question: Have you ever been told that your query runs too fast?

    My advice:
    INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
    The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.

    Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
    Since random numbers are too important to be left to chance, let's generate some![/url]
    Learn to understand recursive CTEs by example.[/url]
    [url url=http://www.sqlservercentral.com/articles/St