This seems to be addressing a different issue to the one I was trying to solve. First of all, it's pretty tied to SQL server 2005 and above - e.g. use of "sys.objects" rather than "sysobjects" - I wanted to retain the backwards compatibility, at least for the time being!
Adam Tappis (1/2/2009)
It's not got lot's of bells and whistles, but supports multiple tables/schemas (using wildcard in table and schema name)
I think this, together with the omission of a condition parameter, is the biggest indication that it's trying to do something different to what I set out to do. The article starts:
I found myself using DTS fairly frequently to transfer trivial amounts of data from one database to another - frequently fairly small volumes, such as new additions to coding tables, and restoring that one record or two that someone had accidentally deleted.
So I'm not really setting out to transfer large quantities of data from several tables - in fact, I would tend not to use this if the output were more than I could comfortably scroll through and do a quick sanity check. I've got SQL Data Compare - I'm not seeking to reinvent that particular wheel.
It shouldn't need to cursor through the fields either.
It certainly doesn't need to use a cursor to iterate through the fields, but I don't really feel any reason not to - I think it makes what it is doing reasonably clear, and performance in this context isn't really an issue, since it is only runs occasionally on quite a small data set (i.e. the set of columns for the single table specified - it wasn't the original intention to iterate across several, in particular since in many cases a condition would be present, and the same condition might well not make sense on several different tables).