First, let me take nothing from the article. It's well written and clear. Well done.
However, the following statement seems to destroy whatever utility was intended in the code...
Note that SETVAR cannot replace dynamic SQL in all situations because SETVAR can only accept a constant value, not a variable or expression on the right hand side,
Further, viewing the duplicates before deleting them implies that this is going to be a manual process anyway.
If you really want something generic, what's so bad about dynamic SQL? It can't be just the fact the everything shows up as red text especially after the code is put into production in the form of a stored procedure.
The other problem indicated is a possible major design flaw. Unless it's a staging table for data, there should be no duplicates in any table. If it's for a staging table, then chances are that the process will be repeated in the future. What's wrong with a hard coded proc to handle the deletes for that table?
Like I said, good article. I just don't see the need for such a thing.
--Jeff Moden
Change is inevitable... Change for the better is not.