• colin Robinson (4/20/2008)


    i would also probably drop the table rather than truncate in this instance. You would then get the same Identity value for each date each time you ran the code.

    I have a question though, isnt there a performance impact of creating dim_time in this way with say a five year end date, as drop downs etc in front ends would be larger than required, and each date would create a null value in the fact table for every measure as the cube processes

    Im thinking we should use code like the example in a slowly changing dimension with code in an if block

    ie if Getdate() >= (select max(date) from DimTime) then

    exec createDates 30(x num) days more data

    an advantage to this is we would never have to revisit the time dimension unless there was a fundamental change like the Fiscal year dates changed and even this would just be a change to the sproc for future dates.

    Truncation of a table results in the IDENTITY column being reset to its original seed... there is no need to drop the table to achieve this result.

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