Delete Incremental Load of Data without Identify Column or DateTime Stamp

Question

Post reply

Delete Incremental Load of Data without Identify Column or DateTime Stamp

Welsh Corgi

SSC Guru

Points: 116520
More actions
March 30, 2012 at 12:06 pm

#271253

I performed an initial load of data into hundered of tables.
I did not create the tables, if I had, I would not have this problem
How can I delete an Incremental Load of Data without Identify Column or DateTime Stamp, Row_Number?
The tables need to be altered and columns added with defaults but what if I did not do this?
For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply

Lynn Pettis SSC Guru Points: 442467 More actions · Answer 1

Only things I can think of off the top of my head.

One, do you have a backup prior to the load you want to delete?

Two, can you use the input for the load to identify the data you need to delete?

Three, if all else fails, can you recreate everything from scratch?

Sorry if all I can give you right now is a bunch of questions.

Jeff Moden SSC Guru Points: 1004638 More actions · Answer 2

If there's something that uniquely identifies the rows (such as a PK or other candidate column), load the incremental data into a staging table, delete all the rows in the target table that are contained in the staging table using a simple join on the "unique" column(s), and then insert the incremental load.

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

Dwain Camps SSC Guru Points: 86978 More actions · Answer 3

This might also work for you:

CREATE TABLE #abc (ID INT, val VARCHAR(10), other CHAR(4))

CREATE TABLE #load (ID INT, val VARCHAR(10))

INSERT #abc (ID, val)

SELECT 1 AS ID, 'ABC' as val UNION ALL SELECT 2, 'DEF'

UNION ALL SELECT 3, 'EFG' UNION ALL SELECT 4, 'HIJ' UNION ALL SELECT 5, 'KLM'

ALTER TABLE #abc

ADD CONSTRAINT def_other DEFAULT 'ABC' FOR other

SELECT * FROM #abc

INSERT #load (ID, val)

SELECT 3 AS ID, 'EFG' AS val UNION ALL SELECT 4, 'HIJ' UNION ALL SELECT 5, 'KLM'

UPDATE a SET other = DEFAULT

FROM #abc a INNER JOIN #load l ON a.ID = l.ID

SELECT * FROM #abc

DROP TABLE #abc

DROP TABLE #load

Users UPDATE only compared to Jeff's suggestion of DELETE/INSERT.

My mantra: No loops! No CURSORs! No RBAR! Hoo-uh![/I]
My thought question: Have you ever been told that your query runs too fast?

My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.

Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
Since random numbers are too important to be left to chance, let's generate some![/url]
Learn to understand recursive CTEs by example.[/url]
[url url=http://www.sqlservercentral.com/articles/St