Сам обмен данными происходит по запросу?Например - да.
А что если в этом запросе 1000000 записей?Это много? Номенклатурных единиц у MB - порядка 1.5 миллионов. Но в наличии на складе - на порядок меньше, был оборот за последний месяц - на два порядка меньше. А отгруженных конкретному контрагенту - десятки-сотни-тысячи. А в конкретном случае заинтересовать может на какую сумму была отгрузка в прошлом месяце контрагенту X и тогда это одно число.
да, тут конечно может быть выигрыш.безусловно он есть по факту.
А если вы вместо переменной используете временную таблицу, у оптимизатора будет больше вариантов выполнить запросы более оптимально.Как показала фактическая практика последних лет 15 - @table работает эффективнее #table/##table. И планировщик прекрасно с ними обращается.
Пассаж про cte не понял - в SQL server, в отличие от postgres (хотя и там вроде в последних версиях есть варианты), cte всегда "инлайнятся", как вьюхи - вместо имени cte подставляется выражение и план строится для всего запроса целиком.Опять же фактическая практика показала, что во многих случаях join @table оказывается быстрее join cte (@table наполняется тем же что было в cte)
разве нельзя как-то определить причину?Как убитый может определить причину своей смерти?
У меня была идея, что бы моё приложение после каждого запуска записывала, что оно начала работать (например, Старт), если пользователь сам закрыл программу, то записать в файл Успех, а если будет не Успех (тот самый случай, когда прогу закрыл не пользователь), тогда ничего не запишется, логично. Но! Когда пользователь заново запустит програму она увидит, что последняя запись в файле будет Старт, она поймёт, что последний раз завершилась не пользователем и будет искать причину в логах винды. Файл выступает в роле логов приложения.Это и есть то самое "прошлый раз приложение было завершено неизвестным образом".