Очень долго формируется отчет #801402

Добрый день, прошу вашей помощи! Строю отчет в скд, в в конструкторе запроса, добавляю необходимые измерения из регистра, один реквизит из табличной части документа и  ставлю условие - период, связи через левое соединение, отчет грузится невероятно долго, хотя к нему нужно еще одно измерение другого регистра прикрепить с условием отбора... вот текст запроса: ВЫБРАТЬ ГДЕ     ДилЗаказТабличнаяЧасть1.Ссылка.Дата МЕЖДУ &НачалоПериода И &ОкончаниеПериода СГРУППИРОВАТЬ ПО     Потолки.Площадь

Странное какое-то соединение:

ПО Потолки.Регистратор.Ссылка = ДилЗаказТабличнаяЧасть1.Срок

Регистр - шляпа

Потолки.Регистратор.ТабличнаяЧасть1.Срок = илЗаказТабличнаяЧасть1.Срок Так вернее будет?

Шляпник, дай совет лучше)

какой-то ужас в

Позовите программиста

если у тебя есть срок и регистратор нахрена соединять?

+100500

почему запрос к реальной таблице регистра? Почему таблица регистра слева, а ТЧ документа справа? Что вы вообще собрать хотите?

Да, сделай так. У тебя количество записей регистра умножится на количество строк в документе.

Из таблицы регистра вытаскиваю почти все, из ТЧ док-а только одно поле-Срок, нужен отчет, без группировок, по колонкам- срок - код - материал - площадь - заказчик. Сперва это, после приделать регистратор состояния потолка, через него отбирать только готовые.

у тебя выбирается вся таблица регистра без ограничения вообще. Уверен, что тебе это надо?

Нет, мне нужно только 4 измерения, соединение начал делать по той причине, что сроки начали прописываться там, где даже нет записей о них, и в стремлении к соответствию данных попробовал соединить таблицы

а, т.е. ты даже не понимаешь о чем я говорю. Ну ок.

В вашем регистре добавьте реквизит - срок. Не придеться выполнять соединения.

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

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

Нужна проверка заполнения срока по регистру?Типа в документе срока нет а в регистре он вдруг появился?

Вы не поняли о чем я говорю. У вас берется вообще вся таблица. Представьте себе регистр в виде большого шкафа. В шкафу на полках стоят некие папки с документами. Вам нужно выбрать некоторые документы. И вы для этого берете и весь шкаф переворачиваете. Зачем вы так делаете?

Бери стандартную обработку "Консоль запросов", идет вроде с ИТС и отлаживай в ней свой запрос. Вначале задай более жесткие условия чтобы запрос не завис и что-то хотя бы вывел, потом убирай лишние условия

Нехорошо издеваться над ребенком

я не издеваюсь, я пытаюсь объяснить. Вопрос в - почему долго строится отчет, я на пальцах объясняю почему он долго строится.

Я сомневаюсь что у него настолько большая даже файловая база, чтобы были проблемы с производительностью из-за того что он телегу впереди лошади ставит. В его случае лошадь будет толкать телегу достаточно быстро если было бы наоборот.

Во-первых, мы не знаем. Во-вторых, это не повод писать тупой код. Стремиться к хорошему нужно всегда.

Сколько в регистре накопления "Потолки" у Вас записей?

Тупой не тупой, главное что работает, это для новичка большое достижение. А искать узкие места в плане производительности должен архитектор, а не новичок.

И вы считаете себя хорошим специалистом?

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

Заказчик считает меня хорошим специалистом))

я прям представляю эти решения.

может просто разницы не понимает

написать внешнюю печатную форму - это не проект

1) Перенес почти все данные из 1С 7.7 Комплексная в 1С:8.2 Комплексная автоматизация   2) "с нуля" разработал конфу, перенес данные из старой программы Delphi, и организовал обмен с 1С:ЗУП? Продолжать?))

конечно продолжай

По порядку, беру из регистра Потолки необходимые измерения- колонки которые будут выводиться в отчете, (Площадь, Материал, Заказчик, Код) т.к. реквизиты из табличной части документа регистратора я включить в запрос не могу, приходится записи подтягивать из реквизита табличной части документа (ДокументДилЗаказ.ТабличнаяЧасть1.Срок) записей в регистре накопления потолки пока несколько тысяч, т.к. база молодая, но в день появляется около сотни записей. Далее устанавливаю связь через регистратор, коллега подсказал связь делать через Регистратор.Документ.Ссылка на Доккумент.ТабличнаяЧасть.Срок. Условие пока только на период.

Теперь Вы сэр)))

тут пальцами ты машешь,мне это не нужно)

Как долго формируется отчет, больше 15 секунд?

Я так и знал))

У меня на прошлой работе была внешняя обработка в ней учитывалось рабочее время и считалась зарплата, вместо того чтобы изменять ЗУП менялась эта обработка, в ней было 15 тыс. строк кода, я бы назвал ее тоже проектом

Мне и нужны все записи о потолках в периоде, позже будет отбор по состоянию потолка, но так как я пока не могу связать регистр с документом не берусь туда еще один регистр СостояниеПотолков привязывать

больше 15 минут

Ой нет, у меня слов нет. ТС, тебе тут товарищ "Троекуров" пусть помогает, вы, похоже, нашли друг друга

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

Посмотри курс по запросам от @Groovy хотя бы. Чтобы основы основ понимать.

>ПО Потолки.Регистратор.Ссылка = ДилЗаказТабличнаяЧасть1.Срок 1) ".Ссылка" здесь не нужно, это лишнее соединение 2) у тебя во всех документах по одной строке?  У тебя  получается что все строки ТЧ одного документа - соединяются со всеми записями регистра по этому документу. Т.е. если в документе 100 строк (и записей сто) - то в результат по этому доку выведется 100*100 = 10 000 записей

Спасибо, обязательно посмотрю, вся проблема в том, что с связанными таблицами сталкиваюсь впервые... то есть мне достаточно использовать   Потолки.Регистратор= ДилЗаказТабличнаяЧасть1.Срок? Нет, в документе то количество строк, сколько потолков менеджер к нему прикрепил.

>ПО Потолки.Регистратор.Ссылка = ДилЗаказТабличнаяЧасть1.Срок Ты дату или число (срок) сравниваешь с документом (регистратор)?

Дату.

А зачем?

Сравнивай одинаковые типы, а то ты дату с ссылкой на документ сравниваешь

Отчет тебе вообще правильную таблицу выдает?

тогда так ДилЗаказТабличнаяЧасть1.Срок=Регистратор.ТабличнаяЧасть1.Срок

Последний раз таблицу выдавал правильную, но происходило как заметил , число записей по одному документу дублировалось в количестве его строк

мыши плакали и кололись

Как правильно сделать соединение, я скоро уже сам мышью плачуще-колющейся стану...

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

Может все на поверхности и мне нужно добавить не один лишь реквизит Срок, а вместе с табличной частью? Тогда и связь автоматически заполняется...

ТАк пробуй че спрашиваешь!

Отчет начал формироваться, быстро и без дублей, всем большое спасибо за терпение!)

Любопытная скушала?))

ты прикалываешься? Хотя о чем это я... Да, вы великие спецы, постараюсь держаться от вас подальше, чтобы не дай бог не навредить вашей репутации.

Главное понять почему Регистратор.Ссылка это ужасно.

Пусть автор почитает совсем небольшую книжкуSQL для чайниковАвтор вроде ТейлорИначе он нихрена не поймёт как и зачем таблицы соединяются

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

Спасибо, прочту)

Да нафиг тебе эти книжки по SQL, это уж потом для общего развития. Для начала набери на ютубе: "1С запросы" и вдумчиво послушай там курс видеоуроков и в обработке "Консоль запросов.epf" поиграйся с запросами.

Благодарю за материал, буду развиваться)