Итак имеем журнал документов, в котором регистрируются 17 видов документов. Включены 3 отбора, 2 из них по графам журнала и один по критерию отбора (Склад).

Теперь собственно проблема.
Если установить большой интервал в журнале (например больше года) журнал начинает дико лагать вся 1с подвисает пока этот журнал не закрыть или не уменьшить интервал. Путем долгих разборов выяснено что тормоза наступают именно при включенном отборе по критерию. Если   выключить отбор по критерию и даже поставить больший интервал - журнал летает.

Странности.
Такое поведение наблюдается не во всех сеансах. Закономерность не ясна. Сейчас имею под рукой такой сеанс с запущенным отладчиком. Замер производительности ничего не показывает! Как будто нет тормозов. Все алгоритмы в отрабатывают за доли секунды по замерам. А форма журнала в реальности может зависнуть и на минуты. Вот так.

Куда копать? В поиске ничего не нашел.
Спасибо.

ЗЫ Платформа 8.2.13.219 хотя такое наблюдал и раньше на 8.1

критерии отбора зело тормозные всегда были

А как без них если мне нужна выборка одновременно по складу получателю и по складу отправителю? Две графы не подходит.

(3) а эти поля точно у вас проиндексированы? Ну, склад-получатель, склад-отправитель?

(4) нет, в статьях Гилева написано что не нужно их индексировать. Включение в критерий - уже явный индекс.

Проставил "Индексировать" для ВСЕХ полей входящих в критерий "Склад" - безрезультатно, затем поставил "Индексировать с доп. упорядочиванием" -тоже без толку. :(

небось стопицот расчетных колонок выводится

а графы журнала индексированы?

(7) смотри внимательно (0) при отключенных отборах которые увеличивают выборку - а журнал работает идеально.

Расчетные колонки есть не скрываю но влияние их нулевое.

(8) только что про индексировал - в пустую.

Еще из непонятого

Вид отбор по критерию склад стоит "Равно" и собственно склад. Имеем дикие тормоза.

Ставлю "В группе из списке" кидаю туда склад - работает плохо но хотя бы не зависает.

up

А процедуры ПриПолученииДанных и ПриВыводеСТроки есть? Можно в целях эксперимента их попробовать отключить

(13) ничего не изменило
Проблеммная база 25Гб MS SQL2005, на маленьких все летает

а нет ощущения, что теряется соединение и оно виснет в попытке восстановить?

так и должно быть... это огромная таблица ведь..

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

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

(18) этот критерий нужен, т.к. графами не реализовать выборку по условию ИЛИ для склада получателя/отправителя. Он единственный собственно и томрозит

(19) Т.е. в критерии оставлены только такие "сложные" отборы (у одного документа 2 реквизита или реквизит в таб.части) и исключены документы, у которых в критерий входит только 1 реквизит шапки?

(21) да

Не хотите попробовать динамический список на управляемой форме?

(22) Я пока не имел дела с динамическими списками, но там вроде есть понятие "основная таблица". А здесь 17 документов. Или основная не является обязательной?

(23) а, туплю похоже - основная будет не документ, а журнал

(23) Там можно свой запрос написать. Практически я с упр.формами, просто знаю, что есть такое :)

"Практически я с упр.формами не работал"

(17) при отборе и тормозит - минуты на 2-3

(27) да именно при включенном отборе

апп

up

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

где гарантия что мой запрос будет в точности соответствовать тому что генерирует сама платформа при работе журнала?

ну запусти технологический журнал, может там покажет..

Вопрос так и не решен.
Видимо придется писать в 1с