• Jeff Moden (2/2/2013)


    One of my principles of the help I get on this forum is to never put a line of code in production I don't completely understand.

    That's absolutely the correct spirit!

    I believe the best thing for now would be for you to read the linked article. It explains a whole lot that I would only be regurgitating here. If after reading it, you still have questions about how it works, then c'mon back and we'll do our darnest to explain it. I guess the simplest explanation is that it works pretty much the same way that you'd do a running total in a spreadsheet without using the SUM() function.

    I'll second Jeff's comment. The article provides the most comprehensive explanation of the rules around the QU that I've ever seen. Pay particular attention to the CLUSTERED PRIMARY KEY on the temp table and OPTION (MAXDOP) hint on the query, both of which are explained in the article, because those two items are the key to making it work.


    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