Home Forums SQL Server 2005 T-SQL (SS2K5) Creating dynamic master insert proc with identity column needing to be omited RE: Creating dynamic master insert proc with identity column needing to be omited

  • Luis Cazares (4/7/2016)


    Lynn Pettis (4/7/2016)


    This:

    INSERT into [JP_CDM].[case]

    SELECT

    *

    --ucn,

    --lcn,

    --court_id,

    --case_initiation_date,

    --case_restriction_flag,

    --county,

    --date_disposed,

    --recurrent_flag,

    --intestate_testate_flag,

    --case_referred_to_mediation_flag,

    --contested_flag,

    --jury_trial_flag,

    --outstanding_warsumcap_flag,

    --pro_se_flag,

    --record_source,

    --record_state,

    --create_user,

    --create_date,

    --maint_user,

    --maint_date

    FROM

    #case_tmpTable;

    select * from #case_tmpTable

    Is not going to work as there are not an equal number of columns between [JP_CDM].[case] and #case_tmpTable since you dropped the identity column from #temp table.

    Actually, it would work because it would ignore the identity column.

    CREATE TABLE Source_Test(

    case_id int IDENTITY(1,1),

    SomeString varchar(30),

    SomeDate datetime,

    SomeValue decimal(10,2)

    );

    INSERT INTO Source_Test(SomeString, SomeDate, SomeValue)

    VALUES

    ('A', GETDATE() - 3, 15),

    ('B', GETDATE() - 2, 25),

    ('C', GETDATE() - 1, 35),

    ('D', GETDATE() , 45);

    CREATE TABLE Destination_Test(

    case_id int IDENTITY(1,1),

    SomeString varchar(30),

    SomeDate datetime,

    SomeValue decimal(10,2)

    );

    SELECT *

    INTO #case_tmpTable

    FROM Source_Test;

    ALTER Table #case_tmpTable

    DROP COLUMN case_id;

    INSERT into Destination_Test

    SELECT *

    FROM #case_tmpTable;

    DROP TABLE #case_tmpTable;

    DROP TABLE Source_Test;

    DROP TABLE Destination_Test;

    I'd still prefer to use the columns, though.

    Cool, learned something I always avoided doing. Never wanted to take the chance that something may change. Never rely on the order the columns are defined when the table is created. You never know when a column may be dropped and recreated with another data type changing the position of the column in the order of definition.

    Ran into this at a previous employer where we added a column with a different data type, converted the data from the old column and inserted it into the new column, dropped the old column, renamed the new column to the old column. This immediately broke code that relied on the order of definition. The out going developers said they didn't want to be bothered with typing all the column names. Just lazy.