Коллеги! Сделал менеджер временных таблиц, сделал запрос в конструкторе, описал в нем втшку сделал запрос. Второй раз не дает открыть в конструкторе! Говорит нет таких полей у вас! А я рассчитываю еще в 4 запросах использовать эту таблицу. Мне их как в конструкторе менять? Помогите тупому!!! Ну не может же быть, что бы все врукопашную!

А ты как делал?

Запрос = Новый Запрос;
Запрос.МЕнеджерВременныхТаблиц = Новый менеджерВременныхТаблиц;
Запрос.Текст = "ВЫБРАТЬ Ссылка ПОМЕСТИТЬ Вт ИЗ Справочник.Номенклатура";
Запрос.Выполнить();
Запрос.Текст = "ВЫБРАТЬ Первые 1 Ссылка ИЗ вт УПОРЯДОЧИТЬ ПО Ссылка.Наименование";
Запрос.Выполнить();

По такой схеме? Тогда конструктор не увидит точно.

да, по такой именно. Неужели никак? Ну все же сталкивались такой проблемой, неужели все так плохо?

копи-пасте ))

От жеж блин!

Копипаста не канает. Суть дела - я получаю договоры с кучей условий в ГДЕ А потом из этой таблицы в разных запросах получаю всякое по разным ГДЕ, соединения делаю. Это обработка если что, не отчет. По разным кнопочкам разное делает

(2) Почему плохо? Ты предлагаешь в конфигуратор встроить противоестественный интеллект?
А вдруг текст запроса на вт будет лежать во внешнем файле? Откуда конструктор узнает, что там взбредёт в голову, не выполняя запроса?

(6) Ладно, ругать древние технологии 1С уже скучно. Просто конструктор запросов забывает описание временной таблицы. А мог бы где нибудь хранить Еж же всякие секции с фигурными скобками в запросах и т.п. Для этого ии не нужен

(7) Исчо раз. В тексте пишу
текстДокумент = Новый текстовыйДокумент;
текстДокумент.Прочитать(ПутьКФайлуКоторыйВвелПОльзователь);
Запрос.Текст = текстДокумент.ПолучитьТекст();
Запрос.Выполнить();

Что должен запомнить конструктор?

(0) Причем тут конструктор, если ты вт в другом запросе создаешь? Или ты не в курсе про пакетные запросы?

(0) Соедини 4 запроса в один пакетный запрос.

(2) Все плохо. Поэтому все изо всех сил стараются не использовать менеджеры временных таблиц.
(5) И зачем тебе тут менеджеры временных таблиц? Или ты это в толстом клиенте делаешь и держишь соединение с БД всю дорогу работы с обработкой?

(11) Ваще то да, в толстом клиенте :)
Запомоился, в обычных формах работаю.

Хотел ускорить работу обработки. просто то одно надо прорисовать в табличке, то другое. Но все на основе заранее отобранных договоров.

Кстати, все не так плохо. Открыть не дает только там где группировка и агрегатные функции. Если просто отбор по ГДЕ - все работает в конструкторе

(12) Ну, такое... Лучше вытаскивай отобранные договора на клиента и передавай их в каждый запрос вместо того, чтобы держать их во временной таблице и удерживать все это время соединение с БД.
Не миллионы же их там у тебя. Если реально очень много, то проще дублировать их отбор в каждом запросе. Да, некрасиво и накладные расходы. Но удержание временной таблицы на сервере - тоже такой себе костыль.
Исторически менеджеры временных таблиц появились до того, как появились пакетные запросы. Как только появились - использование менеджеров минимизировалось.

(14) отобранных договоров порядка 17 с половиной тыс. Получение их запросом - порядка 1200 мс в среднем. Повторять в каждом запросе - ну так себе. Была идея держать в ТЗ и грузить ее в каждый запрос в втшку, но интересно насколько это дольше использования менеджера временных таблиц?

если хочешь через точку, то нужно выразить делать

(15) Неприятная ситуация. По возможности - избегайте этого :)

(14) Я так и не понял, какие аргументы за то, чтобы таскать одни и те же данные с клиента на сервер и обратно много раз. Сплошные минусы.

(18) А держать временную таблицу на сервере БД пока открыта форма - сплошные плюсы?

(18) (19) Видимо лучшим выходом будет получить один раз и держать в памяти массив

(0)
вместо "ВЫБРАТЬ Первые 1 Ссылка ИЗ вт"
делай "ВЫБРАТЬ Первые 1 вт.Ссылка ИЗ вт"

Я в своей толстой консоли запросов убрал бесконечное удержание менеджера https://www.hostedredmine.com/issues/887410 . Внутри есть ссылка на предысторию (одну из). В итоге больше часа держать менеджер временных таблиц на продуктивном сервере по факту - плохо. Однако вразумительного объяснения этому даже разработчики платформы не дали, хотя рассказали, что делали тесты на эту тему и они подтверждают это мнение.

(0)
втыкаешь типа того в каждый текст запроса


|ВЫБРАТЬ
|    ЗНАЧЕНИЕ(Справочник.Вася.ПустаяССылка) КАК Вася,
|    ЗНАЧЕНИЕ(Справочник.Федя.ПустаяССылка) КАК Федя,
|       0 Как Матрёна,
|       """" как Маша
|Поместить ТвояТабличка
|;

далее твой текст запроса. Усё, в конструкторе творишь, че надо, потом, через ТекстЗапроса=Сред(ТекстЗапроса,Стрнайти(ТекстЗапроса,";")+1);
имеешь свой текст..
Поля задаешь какие были в твоей таблике в менеджере.

с нужными типами

Табличная часть в обработке не поможет?

А разве экспортную переменную объявить МВТ в обработке это плохо?

Текст модуля :

Перем МВТ Экспорт;
Перем ПервыйРаз Экспорт;


Процедура ЗаполнитьСписокДоговоров();

Запрос = Новый Запрос;
Запрос.МенеджерВременныхТаблиц = МВТ;
Запрос.Текст = "ВЫБРАТЬ Ссылка ПОМЕСТИТЬ Вт ИЗ Справочник.Номенклатура";
Запрос.Выполнить();
КонецПроцедуры;

Функция2();
Функция3();
Функция4();
Процедуры1();
Процедуры2();
Процедуры3();

МВТ = новый МенеджерВременныхТаблиц;
ПервыйРаз = Истина;

ЗаполнитьСписокДоговоров();

==========

А потом везде используешь переменную МВТ и обращаешься в запросах к своей таблице ВТ, ну или как советуют сделай пакет запросов.

(26) это плохо. МВТ может жить долго и бесконтрольно

(0) наверно пытаешься через точку обращаться к полям полей ВТ?

(26) На всякий случай если в (22) не увидел ссылку, дам прямую http://devtool1c.ucoz.ru/forum/2-1071-1

(22) "больше часа держать менеджер временных таблиц на продуктивном сервере по факту - плохо"
Почему? МВТ это всего лишь некий список-перечень временных таблиц, созданных на sql-сервере, и деструктор, который при вызове удаляет временные таблицы с сервера. Кому мешают лишние временные таблицы? Место в tempdb занимают разве что - так это мелочь..

(30) ничего себе мелочь. На больших базах уложить темпдб неоптимальными запросами - плевое дело

(22) круто, давно ждали эту фишку

(31) Так речь не об неоптимальных запросах, а о простаивающих временных таблицах, не влияющих на производительность

(30) Я же написал в (22) что сама 1С не может вразумительно объяснить это явление, но есть много свидетельств, что деградация происходит и на опытах самой 1С также воспроизводилась. Точные условия не обозначаются. https://partners.v8.1c.ru/forum/topic/1423290#m_1423290

(33) temoDB не резиновая. Часто под неё выделяют отдельный шустрый SSD, объем которого относительно небольшой

если тебе нужно долго удерживать временную таблицу, это попахивает кривой архитектурой. К тому за время существования ВТ исходные данные могут на сто раз стать невалидными. Идеальная ВТ, как и идеальная блокировка, должна жить как можно меньше

(34) Помню, в sql2000 был документированный баг с временными таблицами, когда они физически не удалялись, а лишь помечались как неактивные в контексте сессии, в результате каждое следующее создание временной таблицы было всё более тормозным. В 1с7 это было критично настолько, что даже специальный костыль придумали в 1с++ для обхода бага, чтобы периодически делался реконнект к серверу для очистки контекста временных таблиц. Но в более новых sql вроде бы этого бага нет..