Абсолютно не согласен - в данном случае курсор будет всегда быстрее, причем не в один десяток раз. Сами вдумайтесь - курсор получается из select-а, т.е. операцией чтения. В приведенном же случае мало того, что вы каждый раз select-ом выбираете одну запись, так потом еще и вызываете неявную транзакцию и удаляете запись !!! Простой пример - что легче - купить в магазине килограм картошки и дома, сидя перед компом очистить ее или же каждый раз бегать в магазин за новой картофелиной ? Кстати совершенно недавно ради интереса в SQL2K сделал тестовую таблицу на миллион записей и в ХП просто прогнал по ней курсор, чтобы цикл не крутился в холостую поставил внутрь переменную счетчик, чтобы на выходе подтвердить, что все записи обработались. Работало меньше секунды. Другой ХП я сделал примерно такой же вариант обработки, как в предложенном примере. Устав ждать я просто прекратил запрос. Кстати после этого теста я изменил свое мнение о курсорах и не гнушаюсь ими пользоваться, когда это действительно оказывается эффективнее, чем обращение к любым операциям, вызывающим физическую запись данных в БД. Еще в догонку - насчет таблиц типа declare @Table table тоже обольщаться не стоит, запись в них происходит тоже не особенно быстро, чему я очень удивился, так как они вроде бы по BOL сидят в памяти и не участвуют в транзакциях.

flider:
мы рассматривали только вариант перелопачивания записей, предложенный автором темы. Естественно все что можно сделать запросом никогда не нужно делать курсором. Однако для ситуаций, когда действительно требуется пошаговая обработка записей, согласитесь, курсор является наилучшим и быстрым решением. Единственное, что я делаю, когда на MSSQL садяться люди, только что слезшие с БД индексно-последовательного доступа (FoxPro, Clipper, ...) - сразу предупреждаю, что за использование курсоров их ждет суровая кара, т.е. пытаюсь изменить их взгляд на обработку данных. Сначала правда они на меня обижаються, но потом говорят спасибо, так как уже сами могут трезво оценить ситуацию, когда действительно без курсора не обойтись.