Часто приходится писать пакетные запросы с большим количеством временных таблиц (доходит до 100). В основном для отчетов на скд. В результате получается очень большой список на закладке "Пакет запросов" конструктора. Большую часть временных таблиц (за исключением таблиц, участвующих в последнем результирующем запросе) необходимо уничтожать после выполнения последнего запроса, в котором она использовалась. Собственно вопрос: кто-нибудь пытался автоматизировать эту задачу? Необходимо в пакетном запросе прописать уничтожение ВТ после ее последнего использования. Понятно, что задача не сложная, можно разбить текст по запросам опираясь на ";" и найти имена временных таблиц по "поместить", но может есть что-нибудь готовое?

можно не уничтожать, система сама уничтожает...

(0), ходят слухи, что ручное уничтожение не требуется. Но никто точно сказать не может. Точнее споров много.

а если транзакция оборвется, ВТ уничтожится?

(0) "Часто приходится писать пакетные запросы с большим количеством временных таблиц (доходит до 100)."  Есть подозрение, что что-то не так со структурой данных.

А вообще, 1С могла бы в конструкторе сделать галочку "автоматическое удаление временной таблицы", дабы 1Ска сама это делала

(0) Уничтожать имеет смысл при неоднократном использовании тех же имен ВТ в рамках одного менеджера ВТ, и никак иначе.

(3) Уничтожится, не боись.

* 1С могли бы

(1) В какой момент система уничтожает? Временные таблицы в моем случае находятся в TempDB на SQL. TempDB расположен на рамдиске (диск в оперативке) и место на под TempDB ограничено. Вот если бы наверняка знать, что таблица будет уничтожена после ее последнего использования, а не после выполнения всего пакета, то вопросов бы не возникало

(4) Что-то не так со структурой мозгов у руководства, которое требует такие отчеты)

(9) Используй вложенные запросы)))

(1) зачем же это реализовали?

(9) Вероятность 100 раз создавать многомегабайтные таблицы КРАЙНЕ МАЛА, либо ты хреновый программист.

(11), ага, убей SQL, дабы сохранить место для ВТ )

(9) в момент разрушения менеджера временных таблиц, для скд - это окончание вывода данных, для простого запроса - это разрушение переменной "запрос"

(14) дилема ВТ/Вложенный не такая простая, иногда лучше юзать ВТ иногда вложеные запросы.

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

(13), так всё же. Когда очищаются ВТ ? Мне тоже интересно

(17) Когда запрос отработает

(16), составители рекомендаций от 1С с тобой не согласны

(18), (15) то есть, если я грохну переменную "Запрос", то сразу грохнуться и все ВТ этого запроса?

(15)+ на самом деле за разрушение ВТ отвечает сборщик мусора... и именно по этому всякие незакрытые транзакции, блокировки и т.д не мешают их очищать...

(14) Здесь вопрос что вам нужно Мало опреративы или мало обращений к sql

(20) да
(19) у каждого свое мнение к читабельности кода, собственно я пробовал мерить производительность и понял, что разнице нет.

(20) Нет. Все не так.

В 8.2 когда грохается Запрос, МенеджерВТ, СКД - ВТ очищаются, но остаются жить как пустые объекты пока жив сеанс пользователя sql. (пока сервер 1С подключен к SQL).

В 8.3 ВТ очищаются и удаляются.

(20) маленький секрет если вы грохните до выполнение то их еще не будет если после, то их уже не будет, а вовремя выполнения вы его грохнуть не сможете.

(16) "или принудительном индексирование результата"

Необходимость индексирования ВТ КРАЙНЕ мала и редко необходима.

(24), а чем череваты пустые объекты ВТ?
То есть можно не париться и не грохать постоянно в самих запросах ВТ?

(25), а как же тогда УНИЧТОЖИТЬ в тексте запроса? Когда он срабатывает?

(27) Можно не парится, пока не начнешь использовать один и тот же менеджер ВТ; пока не прилетит ошибка вида "Данная временная таблица уже существует"

(29), интересно. Просто у нас есть утверждающие, мол ВТ нужно удалять всегда после последнего обращения. Мол так намного быстрее, лучше и вообще труЪ

(24) таки утверждаешь, что темпдб будет безразмерен если аптайм кластера серверов 8.2 долог?

(30), а потом запросы открываешь, где половина пакетов - удаление результатов других пакетов

(16) а как же "хочу именно вот таким образом", а то ж если вложенными делать, то в итоге с оптимизацией СУБД может получиться совсем другой запрос?

(28) в тексте запроса э то в тексте запроса вы говорили (20)

(30) это хоороший стиль, суть такого подхода - не зависить от косяков будующих релизов платформы.

но тут нужно знать во всем меру, по тому как если у меня 200 таблиц и пытатся их все закрыть в том-же запросе - читабельность упадет ниже плинтуса...

(30) Если у тебя 100 ВТ размером по 10 мегабайт каждая - они заставят распухнуть tempdb очень быстро, если их в пакете сразу же не удалять.
Но 100 ВТ размером по 10 мегабайт - это лютый пздц.

(36), понял. То бишь в случаях больших объёмов лучше сразу удалить, чем тянуть до последнего

(35), ну даже не знаю. Как "стиль" уже очень раздражает.

(37) Я забиваю на такую фигню. tempdb шринкуется ночью.

Предположу что наверное сам запрос не очень оптимизирован, если почитать последнюю моя тему, там я тоже вначале делал 8вт, а к концу концу уже 4...

(36) из личного опыта, база 30 гигов, темДБ примерно 150 гигов....

После оптимизации стало примерно 30... да и скорость увеличилась...

(41) 150 гигов - за день???!!!

Ну я смотрел профайлер и там видно, что после каждого запроса с использование ВТ 1С-ка добавляет в конце запроса "truncate" на эту временную таблицу. То есть таблица очищается, а потом запихивается  в tempdb для последующего использования.

(43) "а потом запихивается  в tempdb для последующего использования"

Че?

(41) это размер файла темп-дб после суток работы, шринк каждую ночь...

а на этом серваке таких баз было 4, тестовая, распределенка и для разработки, терабайтного диска не хватало под четыре 30 гиговые базы, руководству это было обьяснить тяжеловато :)

(16) Пожалей оптимизатор скуля. План для вложенных запросов сильно зависят от текущей статистики, нагрузки, расположения звезд. Сейчас может построиться мега-оптимальный план, а через 5 минут наоборот. ВТ в этом плане намного стабильнее.

(16) Ничего что  движок 1С полностью  заточен под ВТ ? Можно гирлянду складывать .. начинается #t1..... #t23  и так далее

Любая  движковая виртуальная талица ...  провести ... записать... - это временные таблицы и temp

(46) У меня у одного глаза на лоб лезут когда начинаешь разбираться в чужом вложенном запросе... Даже ради того чтобы потом легко было вкурить, можно пожертвовать 2-3 сек спорного быстродействия и писать с ВТ.

(44) Что слышал. Транкейт это не дроп.

(50) Я понимаю, что такое дроп и транкейт. Я не понимаю порядок мыслей в твоем предложении.

(51) Ну на создание временной таблицы тратится время. Видимо быстрее положить пустую таблицу в tempdb, чтобы потом при надобности не создавать новую, а использовать существующую.

(16) Ты в крайней степени не прав.

(20) Нет не так. ВТ грохнется еще до того, как ты рохнешь Запрос, а именно в момент выполнения запроса "Выполнить()". Если конечно не оставляем в живых МВТ

(53) Иногда запрос настолько длинный, что для сокращения тупо проще использовать вложенный запрос.

(21) Сборщик мусора тут не причем.

(55) Запрос нужно писать, что бы он выдавал прогнозируемый результат за прогнозируемое время, а не по количеству строк.

(57) Если потом с тебя потребуют его быстро переписать, то какая-то оптимальность становится не так уж и важной)

Если мне не изменяет мой склероз, то был баг платформы, правда скорее всего еще в 8.1, когда временные таблицы не удалялись если в явном виде не указать уничтожить или не зачистить менеджер.
Исходя из этого я всегда стараюсь за собой подчищать.

(16) Часто видел, когда некоторый прирост проивзодительности давал просто переход на временные таблицы и отказ от вложенных запросов. Причина - несмотря на то, что временные таблицы писались в темпдб план запроса становился более прогнозируемым и оптимальным.

(58) да а в процессе переписывания вдруг неожиданно нужно сделать левое соединение 1 вложенного с предпоследним

(59) в 8.1 было

(57) Переписать запрос с временными запросами проще. Но опять же повторюсь, что при написании запроса на в первую очередь упирать на предсказуемость результат и скорости выполнения.

(62) Лишь бы работало - а уж после жалоб пользователей можно и оптимизировать. Знаю, звучит дико - но деваться некуда, план же требуют)

(62) И вот здесь, имхо, у временных таблиц более предсказуемые параметры - скуль будет формировать план более предсказумео (из-за того, что запрос разбит на более простые части)

(63) План посылается далеко и надолго.
На самом деле рекомендаций по написанию запросов не много и можно их следовать на автомате.

(64) Именно, поэтому временные таблицы в большинстве случаев являются наиболее предпочтительным вариантом.

еще ВТ имеет смысл при программном формировании текста запроса. это куда более понятно и каждую ВТ по отдельности можно открыть конструктором.

Упрощай и оптимизируй способы решения задач, тогда не придётся оперировать десятками временных таблиц.

А по сути вопроса - ВТ уничтожаются автоматически, и уничтожать их вручную требуется в очень редких случаях.

О боже, какая каша в головах...

(0) По теме, удалять желательно после последнего использования:

- Таблица может быть переиспользована далее.
- Уменьшается нагрузка на tempdb в смысле объема инфы содержащейся в данный момент

кстати, в типовых ВТ уничтожаются крайне редко..

(71) Да, если нет уверенности, что размер временной таблицы будет не гигантским, то лучше ее удалять поскорее. В остальных случаях не вижу смысла.

Собственно вопрос стоял по автоматизации вставки в текст запроса строк: УНИЧТОЖИТЬ <ИмяВТ> в нужных местах

(74) Стр = СтрЗаменить(Запрос.Текст, " ", Символы.ПС);
Для Сч = 1 По Стр.КоличествоСтрок() Цикл
Если ВРЕГ(СтрПолучитьСтроку(Стр, Сч)) = "ПОМЕСТИТЬ" Тогда
Сч = Сч+1;
СтрВТ = СтрВТ + СтрПолучитьСтроку(Стр, Сч) + Символы.ПС;
КонецЕсли;
КонецЦикла;
Для Каждого Стр ИЗ СтрВТ
Запрос.Текст = Запрос.Текст + Символы.ПС + "ВоеныУничтожить " + Стр;
КонецЦикла;
100500 на телефон, - 500 за каждую ошибку

(75) за такой код ты платить должен. кровью!

(74) Как выяснили, что это не нужно.