d-stream

Бронебойный вариант:

select
'insert into table (f1,f2,f3) values ('+f1','+f2+','+f3+')'
from ... -- и тут любые соединения, агрегации и т.п.

Выхлоп - тупо 100500 строк инсертов для получателя, которые могут быть выполнены поочерёдно.

При желании и фантазии - можно аналогично под bulk варианты формировать результаты пачками

из очевидных - цикл/курсор
из менее очевидных

use database;
DECLARE @sql NVARCHAR(MAX) ;
set @sql=''
select @sql = @sql+';'+ 'alter table ' + t.TABLE_NAME + ' REBUILD WITH (DATA_COMPRESSION=ROW)'
FROM INFORMATION_SCHEMA.TABLES t
PRINT @sql;
EXEC sp_executesql @sql

(но следует учитывать что sqlexec подавится большим sql)

сгруппировать по дням и категориям и отобрать по условию count(client_id)>1
distinct для исключения повторов - по вкусу

TSQL достаточно строг и поэтому он не допускает полей, которые не участвуют ни в группировке ни в агрегации.

Что собственно логично.

Для "обхода" этой строгости болтающийся рядом id юзера его email при группировке по id - приходится или включать в группировку или же просить min/max (заведомо зная что это якобы лишнее)

Ну а так - можно попробовать представить что же показать в результате запроса простой таблицы id-user-role при группировке по role )

Собственно простой вариант: sp с транзакцией вызывает другую sp с транзакцией, которая может быть вызвана и сама - вот и "матрешка", если не озаботится например проверкой trancount.
Ну и архитектурно - за пределами вложенной транзакции изменения еще недоступны - иногда именно это и требуется.

Ну можно ориентироваться на contragent_type - который определит как минимум 3 сущности: организация (юрлицо), человек (физлицо) и ИП (физлицо с элементами организации), плюс с недавнего времени еще подветочка ИП - самозанятый. В таком ключе - seller - это всегда contragent, а вот в зависимости от contragent_type - в рамках контрагента - уже несколько пересекающихся сущностей. Притом организация - будет включать в себя как минимум кучку персон (директор, бухгалтер, контактные лица, ответственные, подписанты и т.п.). Притом в силу существующих реалий множественности компаний - одно и то же лицо может фигурировать и как фл и как контактная персона в нескольких компаниях и как директор-бухгалтер в еще нескольких...

Ну в тяжелых случаях не исключен например триггер на after, который что-то считает и в качестве результата записывает "обратно". Ну или уж в совсем извращенном варианте "не дает" удалить подавив отлупы)

В принципе для начала стоит посмотреть Dependencies (например пкм на таблице и View Dependencies) и предположить что и кто может влиять.

in подразумевает список
case - подразумевает единственное значение

можно конечно извратиться и сделать нечто типа ... in (case...end) но зачем?

Классический вариант:

where cast(datetime_field as date) = cast(getdate() as date)

Естественно за кадром оставляем нижнюю часть айсберга в виде таймзон и т.п.