Now that I read the article again, I come to these conclusions:

EmployeeNo and EmployeeID are duplicate fields in the Employees table

ID field only exists in the EmployeesCopy table because that was added to make the rows non unique (but somehow it's shown in the Employees table, so I'm a little confused)

I would hope that if there are any other fields in the table, they would match exactly too -- or you've got bigger problems and you shouldn't be doing this to get rid of them

So using the select distinct into EmployeesCopy or select * UNION select * will remove the duplicates as they fill EmployeeCopy -- thus eliminating the need to look at ID > ID or MIN(ID) with a self join.

However, if you choose to use the author's solution and you don't remove the duplicates before filling EmployeesCopy, isn't the delete EmployeesCopy where not in (select min(id)) an example of RBAR?

Would it be better to do it this way?

delete EmployeesCopy from EmployeesCopy a left join (select min(id) from EmployeesCopy group by EmployeeNo, EmployeeID) on a.id = b.id where b.id is null

This uses the set-based power of SQL, so shouldn't it be faster?