• tommyh (1/19/2011)


    Have to say i dont really like the Convert version. There are as i see it multiple "problems" with it compared to DateName (the case version isnt really anything i would consider... unless you ALWAYS wanted the result back in a specific way regardless of language)

    1. DateName helps describe what the code actually does. The Convert gives you nothing. Unless you know exactly what 106 will return and then you have to count to see what part it uses to know whats returned. Sure you can add a comment to remedy this... but you would have to remember to do that.

    2. A change in requirements to return the full name of the month would mean that the Convert wont work at all. Use DateName and its just a change of the nr of chars returned (ergo remove the substring part)

    3. A change in order (instead of "jan 2011" you want "2011 jan") is easier to handle with DateName. The Convert version would just be messy.

    Now okay its faster in a specific situation at a price of readability/flexibility. Okay if your dealing with several billion rows then okay it might be worth it. But for more "normal" everyday usage... nah.

    /T

    True enough. You won't see benefits of the CONVERT method unless you deal with mega-rows on a regular basis. Just so long as you're not using the CASE statement I posted, you should be all set. Thanks for the feedback.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)