• Sure there are. For example, if you convert a Money data-type to VARCHAR so that you get commas and then store that back in a Money data-type, the commas go away because you're not storing it in a VARCHAR anymore.

    On dates and times, you can do a minor bit of formatting but only what gets returned by changing either the base language or by setting the date format to (for example) DD/MM/YYYY instead of MM/DD/YYYY but, behind the scenes, no formatting was actually done because a DATETIME data-type doesn't ever store formatted data. It simply stores dates and times as two integers behind the scenes.

    Shifting gears a bit, it's never a good idea to actually store dates, times, or amounts as formatted VARCHARs because it renders a whole lot of functionality totally useless unless there's either an implicit or an explicit conversion... both of which can be real time wasters and the cause of much unnecessary conversion code. The only time that data should be formatted is either by the front end or when you have to write formatted data to a file. I'd never store formatted data in a permanent table.

    --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)