• wolfkillj (11/12/2013)


    Jeff Moden (11/11/2013)


    Honny (11/11/2013)


    As you mentioned there is no Foreign Keys so truncate and load is better.

    1. If you drop the table again you have to create the table and load.

    2. You have drop the Table if there is any changes in he table structure from previous load that time it is better way but in your case truncate and load is better.

    I don't believe so. I believe that the SELECT/INTO solution that "SQL_Learning" proposed will do the trick and no modifications to the table will be required if the source-query ever changes.

    I don't think SQL_Learning's suggestion meets the requirement. It sounds like Jim1234 wants to do is flush ALL the data from a table and replace it with entirely new data. TRUNCATE and INSERT (or BULK INSERT or other means of populating a table) accomplishes that goal. SQL_Learning's suggestion fits the requirement to delete some rows while retaining others from a table.

    Now, as to whether truncating the table and reloading it entirely anew is the best choice to meet the *business* requirements, I don't know - Jim1234 didn't provide enough information about his process to determine whether he really ought to be truncating and reloading or doing an INSERT/UPDATE.

    So why would you think that dropping the table and rebuilding it using SELECT/INTO wouldn't fit the bill?

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