А то какая-то недоделанная автоматизация.

Вы всё ещё пишете запросы конструктором?

(0) если в условиях в конструкторе ставишь условие на Сумма(...), то конструктор его сам ставит в блок ИМЕЮЩИЕ

(1) а чем запросы писать? неужели руками?

(3) Ну, если руками неудобно - можешь попробовать ногами. Или носом... Или как украинский президент...
Тут большой выбор...

(1) Ну... Есть такое дело.

Меня зовут Галахад, и я конструктороголик.

(2) Не вижу такого.

(1) Конструктором как то быстрее

Я вот тоже конструктором не пользуюсь, пиши руками. Где-то видел вакансию с требованием типа "Умение писать запросы как с конструктором, так и без него" - хз что в голове у hr

(6)
http://screenshot.ru/upload/image/ddpG
http://screenshot.ru/upload/image/ddpP

(9) Я правильно понял?
1. Нужно закрыть конструктор.
2. Скопировать СУММА(...)
3. Открыть конструктор.
4. Вставить.

(10) Нет. Когда конструктором добавляешь условие там на галочке нажимаешь чтобы можно было редактировать строку с услоием и просто Вместо "Реализация.Количество > 100" пишешь "Сумма(Реализация.Количество) > 100"

(10) можешь и не закрывать, сразу в условиях ставишь галочку Произвольное и пишешь условие Сумма(...)...

(7) Анекдот №240927

(13) я видел и обратную ситуацию, приходит дядя программист, садится делать тестовое задание и пол часа таблицы вручную соединяет и правит в СКД, параллельно еще в блокнотике что-то копирует и правит, хотя через конструктор это делается за 1 мин.

(11) (12) Спасибо. Так неплохо.

(14) А вы его тестировали именно на скорость написания запросов, или у вас проект какой был?

(16) ну если кодер вместо работы будет оттачивать скилы написания всего в блокноте, то наверно он нафиг не нужен бизнесу?

(4) в чем профит не пользоваться конструктором запроса?

(0) освой слепую печать

(18) я не пользуюсь когда пишу соединения

(18) Можно написать запрос, текст которого формируется в десятке разных модулей, а потом через полгода смотреть на своё детище и малость охреневать.

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

(18) Профит в удобстве. Конструктор - только для того, чтобы накидать основные таблицы и поля. Ну и итоговый запрос потом чекнуть, чтобы явные ошибки увидеть.
Условия-то всяко проще в тексте запроса руками написать.

Если бы конструктор позволял видеть сразу несколько запросов пакета,то был бы Профит.
А так ctrl c ctrl v быстрее,чем мышковать по деревьям.

(24) Что мешает переходить по вкладкам и смотреть?

Править отчет лучше в тексте, создавать в конструкторе. Одно другому не мешает, я делаю и так и так.
Гораздо труднее в консоли СКД прописывать что-то сложное в ресурсах или вычисляемых полях.
Я уже забыл когда сам создавал отчет кодом, а не в консоли отчетов.
Обычно, если сложный отчет, то сначала отлаживаешь запрос в консоли запросов, потом СКД в консоль отчетов и настройка структуры.
У меня есть отчет где сначала данные собираются из 14-ти регистров, потом обсчитываются, затем группируются по условиям и потом уже в отчет выводятся. Там запрос на 1.5 тыс. строк. Электронная промышленность - она сложная.

Есть запросы, которые если открыть и закрыть конструктором, перестают работать.

Переименование и удаление выгоднее делать в конструкторе, т.к. он понимает "ссылки" на таблицы/параметры/поля и проходит по всем ссылкам и обновляет их. Ручное выполнение этих операций тем опаснее, чем больше область видимости переименовываемого/удаляемого объекта.

(27) прошу дать пример таких запросов, я с помощью конструктора форматирование запроса делаю и хотел бы избежать порчи текста.

(27) Имеются ввиду сложные условия с кучей скобок, которые конструктор может запороть?

(29) ну, соединение 3 и более таблиц

(31)(27) Конкретный пример можно?

(32)  ..и, в идеале, минимально возможный, т.к. сказать компактный и элегантный пример, демонстрирующий, как конструктор "запарывает" тексты запросов🙂

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

(33) у меня есть тема про это, только в итоге я понял, что результат то одинаковый, просто такой запрос корявый для моего понимания.
Вопрос по конструктору запроса

(32) типовые отчеты на построителе, которые импользуют комментарии запроса для замены потом в коде, разве что

(34) Я пишу руками. Не горжусь. Просто удивляюсь, зачем это делать в конструкторе. Неудобно же, если запрос мало-мальски сложнее соединения пары таблиц. В тексте контекст гораздо шире выхватывается и дописать сразу в тексте тоже зачастую быстрее. Через конструктор только то, что там удобнее. Скелет набросать, прочекать/отформатировать, переименовать источник и т.п.
Можно конечно молоточком и шурупы вбивать. Но владение разными инструментами зачастую жизнь облегчает.

(36) Не... с заменами не интересно. Нужен именно пример чтобы ломался конструктором или изменялся результат.

(28) "обновляет" это как? Типовой конструктор не умеет же при переименовании имени поля ВТ обновлять его во всех последующих местах использования. Только в текущем запросе пакета, а из остальных вообще кажется тупо удаляет...

(34) Всегда удивляюсь, почему люди водят машину, ведь таксисты, это проще, чем знать дорогу...

(37)
"Я пишу руками."
"Через конструктор только то, что там удобнее. Скелет набросать, прочекать/отформатировать, переименовать источник и т.п."

(41) + Наверное все так "руками" и пишут.

(42) Зря иронизируешь. Если взять любой непримитивный запрос, то у меня там "ручного" будет больше, чем "конструкторового". Доработка запросов - вообще вручную всегда. Конструктор только как форматтер. Ну и переименовать изредка чего-нить.

(29) (32) буквально сегодня такой состряпал
При использовании конструктора, последние скобки уйдут и будет неправильное отношение.
Сам почти всегда конструктором пользуюсь

ВЫБРАТЬ
    ПартииТоваровНаСкладахБухгалтерскийУчетОстатки.Номенклатура,
    ПартииТоваровНаСкладахБухгалтерскийУчетОстатки.ДокументОприходования,
    ПартииТоваровНаСкладахБухгалтерскийУчетОстатки.СтоимостьОстаток / ПартииТоваровНаСкладахБухгалтерскийУчетОстатки.КоличествоОстаток КАК ЦенаБУ,
    ПартииТоваровНаСкладахОстатки.СтоимостьОстаток / ПартииТоваровНаСкладахОстатки.КоличествоОстаток КАК ЦенаУУ,
    ПартииТоваровНаСкладахОстатки.СтоимостьОстаток / ПартииТоваровНаСкладахОстатки.КоличествоОстаток / (ПартииТоваровНаСкладахБухгалтерскийУчетОстатки.СтоимостьОстаток / ПартииТоваровНаСкладахБухгалтерскийУчетОстатки.КоличествоОстаток) КАК Отношение
ИЗ
    РегистрНакопления.ПартииТоваровНаСкладах.Остатки(ДОБАВИТЬКДАТЕ(&ДатаНач, МЕСЯЦ, 1), ) КАК ПартииТоваровНаСкладахОстатки,
    РегистрНакопления.ПартииТоваровНаСкладахБухгалтерскийУчет.Остатки(ДОБАВИТЬКДАТЕ(&ДатаНач, МЕСЯЦ, 1), ) КАК ПартииТоваровНаСкладахБухгалтерскийУчетОстатки

В чем профит ручного написания запросов? Тренировать память как называется реквизит наименованиеполное или полноенаименование? Тренировать скорость печати, набить 600 символов с клавиатуры, вместо 25 кликов в конструкторе? Освоить команду "Текст"  - "Блок" - "Добавить перенос строки". Научиться писать без опечаток?
Мне даже в параметрах виртуальной таблицы иногда лениво написать запрос для условия В (), думаю почему бы и тут не сделать конструктор запроса

Один момент это объединения иногда там копирую запрос и реально быстрее получается объединения писать.

(45) вообще-то для "В ()" есть конструктор

(45) Вся структура запроса как на ладони. Не надо лазить по уровням вложенности, полям, галочкам и ютиться в полях ввода. Ну и да, мне несложно - я в слепой десятипальцевый умею :) Оно уже мимо осознанных усилий идет - смотришь на экран, думаешь мыслю, а текст сам набивается.

(45) В комментариях

"Не надо лазить по уровням вложенности, ЗАКЛАДКАМ, галочкам и ютиться в полях ввода"
Для меня елозинье мышкой для попадания в разные поля и закладки вместо того, чтобы не отрывая рук от клавиатуры быстренько впедалить чего надо куда надо - выглядит неприятным усложнением.

(44) Не воспроизводится. После конструктора:
|    ПартииТоваровНаСкладахОстатки.СтоимостьОстаток / ПартииТоваровНаСкладахОстатки.КоличествоОстаток / (ПартииТоваровНаСкладахБухгалтерскийУчетОстатки.СтоимостьОстаток / ПартииТоваровНаСкладахБухгалтерскийУчетОстатки.КоличествоОстаток) КАК Отношение

(39) Да, ты прав. В последующих запросах пакета штатный конструктор не делает переименование поля при его переименовании в запросе создания временной таблицы. Перехвалил я его=)
Зато это делает конструктор запроса ИР.

писать конечно конструктором проще. немного доработать проще руками.
А есть же некоторые , что и читают только конструктором

(52) Да нету таких.

(45) Только работает на пустом выражении, хотя тоже вариант, сначала запрос потом его уже обрамлять в условие В (), никогда не пользовался этим конструктором теперь буду

(53) я сам таких видел

(54) Напиши ( ). Выдели пробел. Вызови конструктор.

(51) ну твоя консоль запросов очень удобна для написания запросов руками.

я вот не представляю, как в штатном конструкторе условия на предопределенные элементы вписывать...

(56) Спасибо, так лучше )

(58) Пожалуйста.

Удобство чем писать зависит от уровня владения запросами и умения пользоваться "слепым" набором текста. При этом, вручную - это не обязательно все набирать вручную, это можно копировать поля и части запроса.
Я на начальном этапе овладения 8.0 не представлял как можно писать запросы без конструктора. Потом я овладел слепым набором, и стало любопытно набирать запросы руками. Теперь я не представляю, как можно набирать запросы в конструкторе, и уже стал подзабывать, где и что там находится в конструкторе. Тоже самое и с запросами компоновки, точнее директивами полей для компоновки.

Разница в наборе заметна особенно, где поля должны быть составные, к примеру Выбор Когда ПериодЗавершения ... Конец КАК Поле. обычно такие поля морально убивают адептов конструктора.

(60) У меня было хуже... К моменту знакомства с 8 я вполне уверенно руками писал запросы на чистом sql (t- и pl/)..
И использовать конструктор для написания всего этого... Даже как-то в голову не приходило...