Дмитрий Ковальский: Но они же сами просили "нужно сделать", а я и сделал, но они же не просили сделать это прям - "Вау!". Вот и написали бы, что код должен быть причесан, с комментариями, с обязательным использованием того и того и т.п. =\
На счет отката ... rollback transaction.
Он должен отменить неявную транзакцию insert при которой запустился триггер.
А использую его для того что бы отменить занесение данных в _t1.
А если сделать return, то в _t2 будет пусто, а в _t1 будет болтаться результат insert
можно, а можно было и вообще не использовать #tmp ...
но, я делал просто рабочее и не задавался вопросом правильности (но с замечанием согласен, что так было бы правильнее)
Решение: изобрел велосипед с батником и sql запросом.
Теперь нужный фаил берется ... копируется в новую папочку со вставкой новой строки в начало файла.
После утренней перезагрузки все стало нормально.
Ну, отрабатывает за 3 секунды, а это уже не 1-5 минут.
Подозрение падает на КЭШ процедур, а именно на то место где хранятся переменные всех процедур
(те что использовались и те что используются).
Погляжу сегодня чем мне поможет DBCC ...
Чисто теоретически из - за переполнения переменных не хватало места для моих двух новых, а старые он удалял и добавлял мои, ну, или вообще выгружать куда-нибудь на HDD ...
Ответа пока не нашел ...
Грешить на ожидание в очереди на выполнение как-то тоже не катит ...
думаю надо смотреть DBCC и все что связано с кэшем.
видимо надо юзать ... что-то похожее на это:
DBCC FREEPROCCACHE (0x060006001ECA270EC0215D05000000000000000000000000);
Не, я ее еще не засунул в процедуру ... но она да, будет потом ею.
Сейчас, это просто окошко (песочница) запроса в котором я тыкаю F5 :)
Но, был весьма удивлен такой разницей ...
Ибо мне нужно для выполнения хранимой процедуры переменные даты которые будут браться по условию и отрабатывать то самое чудо ...
Разумеется ... я бы хотел 1 сек, а не минуты :(