Firstly, I'll belatedly add my congratulations for a clear and concise article. It was well written and explained the intent despite the misleading title about the where clause rather than max rows. I've been following the comments ever somce I thought "hmm, a handy emergency brake but does it work and what are the workarounds and deficits?"

Personally I don't aftee with such an approach as a warning since accidentally wiping a live, or near live system is the ultimate way to scare sql developers into better practices.

I know. I was very lucky when I wiped out the email ody text for every email our support staff has spent 4 weeks entering in 14 languages due to a highlightuing of code glitch.. Luckilly another developer had backed up the DB for personal use only 10 minutes before but it could have been bad.

I now train myself to write queries in a certain way so that you first build the select then the update/delete and if you are anywhere other than your personal dev (ITS, UAT or Live) then you never run an update query without a budy. The budy system works great. No matter how simple the query you sit at the screen and talk them though it at each stage before executinng. Anything too complicated to talk through should be part of a tested release.

So for an update statement I may write this initially

SELECT m.*

--UPDATE m SET monkey = 'marmosette'

FROM monkeys m

WHERE MonkyID=2

Then just highlight from the coment to run the script but allways, always have another by my side explaining every step and giving me the OK.

It is though a marvelous example of auto trigger creation for tables whcich could be use to create audit tables. I am sure that has been covered before though.