|
|
|
SSC-Addicted
      
Group: General Forum Members
Last Login: Wednesday, November 17, 2010 3:38 AM
Points: 445,
Visits: 82
|
|
|
|
|
|
SSC-Addicted
      
Group: General Forum Members
Last Login: Wednesday, November 17, 2010 3:38 AM
Points: 445,
Visits: 82
|
|
When you are populating the record set, take out the GO between the next-to-the-last and the last insert statements. Having this penultimate GO in the set of queries will remove the scope of the @NOW variable and cause the last INSERT to fail.
|
|
|
|
|
SSCertifiable
       
Group: General Forum Members
Last Login: Yesterday @ 2:17 AM
Points: 6,862,
Visits: 8,049
|
|
|
|
|
|
Valued Member
      
Group: General Forum Members
Last Login: Tuesday, November 25, 2008 9:48 AM
Points: 57,
Visits: 8
|
|
Hi... I usually clean up my "mess" with "something" like this delete from myTable where myID NOT in (select min(MyID) from myTable group by myUniqueField[s]) But I think the best application for CTE are recursive querries...
|
|
|
|
|
Forum Newbie
      
Group: General Forum Members
Last Login: Tuesday, January 15, 2008 5:59 PM
Points: 6,
Visits: 3
|
|
Is there a performance gain to using this function and technique? Or is it just one of those "hey cool function --- let's use it"?
aries
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Monday, November 23, 2009 4:45 AM
Points: 163,
Visits: 9
|
|
great examples! If only duplicates need to be removed the ROW_NUMBER() may not be needed. WITH cteEmployeeOrderedByMyRank AS (SELECT RANK() OVER (PARTITION BY EMPID,FNAME,LNAME ORDER BY REFDATE ASC) AS PartitionRank , * FROM EMPLOYEE -- WHERE 1 = 1 ) DELETE FROM cteEmployeeOrderedByMyRank WHERE PartitionRank > 1 ; It surely seems to be much faster than the cursor based apporach.
bm21
|
|
|
|
|
Valued Member
      
Group: General Forum Members
Last Login: Sunday, April 17, 2011 1:56 AM
Points: 52,
Visits: 59
|
|
Interesting demonstration of the ROW_NUMBER() function. Please say it ain’t so, Joe! - that you are not using cursors to remove duplicate rows. Even the technique of a SELECT DISTINCT into a temporary table would be a better option. As other readers have commented, there are a number of ways to remove duplicate rows. This would be my approach: DELETE Employee FROM Employee a INNER JOIN (SELECT Empid, FName, LName, MIN(RefDate) AS 'MinDate' FROM Employee GROUP BY Empid, FName, LName) b ON a.Empid = b.Empid AND a.FName = b.FName AND a.LName = b.LName AND a.RefDate > b.MinDate This would still leave the issue of James verses Jim that would need to be resolved separately. If you didn’t care about spelling variations and wanted to assume that the first entry was the correct one then this would work: DELETE Employee FROM Employee a INNER JOIN (SELECT Empid, MIN(RefDate) AS 'MinDate' FROM Employee GROUP BY Empid) b ON a.Empid = b.Empid AND a.RefDate > b.MinDate I would be interested in the question of performance between the two techniques but I’d put my money on mine which I suspect has a whole lot less overhead even as a cross join than having the engine generate a row position.
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Monday, May 20, 2013 4:19 AM
Points: 1,297,
Visits: 193
|
|
Another option (that works with SQL 2000) and even in cases of all the columns having the same value (no column to differentiate the rows), is inserting the result set into a new table with an identity column (or adding an identity column to the original table). After that, it's just a matter of keeping the distinct rows as shown in the comments. I can't remember where I read this solution, but it was either here in SQL Server Central or SQL Team foruns. André Cardoso
|
|
|
|