Роман Дынник 2 ASCRUS
авторВообще то в MSSQL в таких случаях вместо ХП можно использовать UDF, которые вполне нормально можно вызывать в приведенном Вами запросе
Не во всех случаях. MSSQL накладывает кучу ограничений на манипуляцию данными в UDF.
следующую функцию не удастся даже создать:

И хорошо, что накладывает. Вот в Sybase ASA в функциях можно что угодно творить и самое пренеприятное, что все это еще работает и даже без ошибок и довольно шустро. В итоге я "таких примеров" насмотрелся использования курсоров, DML и DDL в функциях, что без 100 грамм не разберешь чего хотел разработчик такой логикой сказать. То же самое касается в ASA и ХП, которые можно в секции FROM использовать - пиши что хочешь, ASA все сделает - только вот ни разу мне не пришло почему то в голову в процедуре, которая используется в запросе DDL или DML накатать ... наверное воспитание такое :)

Вот вот. В общем вместо:
пишите:
и не нарушайте стандарты работы SQL - в конце концов если все разрешено, это не повод начинать безобразия.

Лох ПозорныйСтранные вещи ты говоришь, ASCRUS

Если я использую ХП, то могу что-то куда-то заDML-ить, а потом отплюнуться итоговым селектом, и никакие стандарты SQL при этом не нарушаются. Правда и селект из этой сохраненки я не сделаю.
Если я использую UDF, то ничего никуда DML-ить я уже не могу. Дескать безобразия низзя творить.
Немножко не поняли :) Пользуйтесь наздоровье DML в ХП и UDF. Но извиняюсь неявно во время выполнения запроса организовывать транзакцию - лично для меня диковато. Вы вдумались в запрос, который привел Роман:
Он же вернет единички на все кол-во записей t5, попутно удаляя все эти записи, причем стартует неявную транзакцию, так что после выполнения этого запроса по идее и COMMIT не мешало бы сделать. А если на t5 еще и триггера висят или каскады - вообще чудесно получается - один SELECT, а сколько всего удалилось :)

далее ... не легче ли писать явный DELETE FROM Table с нужными соединениями и условиями, чем заниматься такими странными вещами ?

Роман Дынник ASCRUS
А если бизнес-логику на уровне записи нужно организовать при удаленнии (т.е. в хп)?
...
без транзакций - для простоты.
Кто мешает в ХП вызывать DELETE WHERE ... или даже организовать курсор, если уж так позаписям хочется и на каждую запись курсора делать DELETE WHERE id = @id и вызывать себе CALL StoredProcedured (@Param1, @Param2) ??? Зачем это в SELECT-то пихать ??? Можете привести хоть один пример, из которого было бы явно видно, что это был бы разумный метод изменения данных ?

Роман Дынник ASCRUS
Кто мешает в ХП вызывать DELETE WHERE ... или даже организовать курсор, если уж так позаписям хочется и на каждую запись курсора делать DELETE WHERE id = @id и вызывать себе CALL StoredProcedured (@Param1, @Param2) ??? Зачем это в SELECT-то пихать ??? Можете привести хоть один пример, из которого было бы явно видно, что это был бы разумный метод изменения данных
ASCRUS , внимательнее !

Роман Дынникменя лично очень расстраивает тот факт, что в mssql нельзя вызвать хп в select-e.
т.е. очень удобно, например, написать select xsp_delete(id) from tb.
Приходится извращаться либо ч/з курсоры, либо ч/з временные таблицы.

Т.е. так и делаю в mssql, либо курсором, либо используя временные таблицы для наполнения id-шниками.
Но в sybase то это сделать гораздо проще, короче и лаконичнее ч/з select xsp_del(id) ...
Нет уж - Вы внимательнее :) Я задал вполне нормальный вопрос:
Зачем писать функцию, которая удаляет запись и использовать ее в SELECT для удаления записи, когда можно просто написать DELETE FROM Table ?
И тут уже не важно для какой СУБД, мне просто сама логика такого действия не очень понятна, прошу обьяснений ...

Роман Дынникбизнес-логика - в хп.
Для множественных операций типа delete from table where id in(...)
нужен будет еще один слой(тип) хп типа deleteList в котором практически придется продублировать ту же логику что и для deleteItem, но с учетом множественности.
Не понимаю я, какая может быть такая бизнес-логика навороченная, которую в DELETE прописать нельзя и приходиться специальную ХП писать для этого. Наверное Роман мы просто в разных измерениях мыслим (бывает и такое)