При формировании отчета на СКД (большой объем выводимых данных) начинает поедаться оперативка, в итоге падает клиентское приложение.
Можно ли с этим как-то бороться? Есть ли ограничение на количество строк/столбцов в итоговой форме?

был глюк - если в макете сделать группировку, а потом - еще одну вложенную группировку типа "детальные записи" - то оперативки кушалось примерно в 8 раз больше на построение...

В отчете 4 группировки по измерениям, "детальных записей" нет, и всего 3 таких таблицы (разный порядок группировок и состав колонок)...
Если не делать отбор (например по филиалу) - клиентская часть просто падает молча, либо говорит перед этим "не хватает памяти" (ну и диспетчер задач естессно показывает что вся память занята процессом 1cv8)

мб параметры не указаны для компоновки?

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

3 - какие параметры?

(5) отборы и параметры указаны для компоновщика или где-нить в секции ГДЕ основного запроса? фигурные скобки присутствуют?

мне кажется дело в запросе

(0) оптимизируй запрос или откажись от какой-то части данных
(1) это не глюк, это так и должно быть, ибо детальные записи - это ВСЁ ваще.

(6) да везде, там запрос на 1000 строк и куча параметров, доступных для интерактивного изменения и "скрытых" для юзера, {} - есть тоже
(8) запрос выполняется быстро, максимум за 0,5 - 1 минуту, оптимизировать там уже нечего :( отказаться от части данных не я, а руководство не хочет :) я бы с удовольствием :)

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

может тогда запрос в студию?

(9) а как ты проверял, что запрос выполняется 0.5-1 минут?
(11) лучше не запрос, а схему с настройкой и всеми пирогами

+(12) ну, и - намекнуть, на какой конфе это смотреть

(12)+100500

(12) от 0% до того момента как побежит бегунок вывода в СКД

(8).2 да не, смысл в том, что когда все поля переносишь в группировку - все нормально

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

+(17) а давай ответ автора посмотрим?

(17) ну, я только понял, что чем меньше вложенных группировок, тем меньше жрет СКД, причем в геометрической прогрессии

(19) так так оно всегда было - с итогами и построителем та же история

(12), (15) - да в консоли запросов естессно, она то память не хавает и выводить сразу начинает, не висит, пока вся выборка не выведется
Запрос и схему - не могу к сожалению, конфига вообще самописанная, но сэмулировать ситуацию элементарно - какойнить регистр из 100-1000 записей на самого себя перемножить пару-тройку раз, чтоб на выходе порядка мульёна записей получилось - и вперед, к победе коммунизма (1С-ка точно свалится на таком объеме). Группировку вообще одну можно оставить (т.е. линейная выходная форма) - не поможет.
Вывод - память жрет сама СКД, а это я считаю никакая не фича, а самый натуральный глюк (та же консоль запросов ведь не жрет...).

(21) то есть попыток посмотреть, какой по факту запрос СКД генерит, даже не предпринималось,  я правильно понимаю?

(17) - еще раз говорю, детальных записей нет, только 4 группировки.
Запрос скомпонованный естессно видел, его и копировал в консоль запросов, когдла время замерял.

а что может быть страшного в скомпонованном запросе? там только параметры подставлены, да "представления" для сортировки добавлены, больше ничего помимо самого исходного запроса там и нет....

(23) про детальные записи разговор не про твой случай, расслабьсо

(23) 4 вложенные группировки?

(25) :))) да не напрягался особо :)))

(26) даже если убрать все группировки - ситуация та же

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

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

в оригинальном отчете у меня должно было бы выводиться около 200 000 записей о 30 колонках.... не выводится... на 3Гб клиентская часть с шумом валится...

(29) например? кроме того что я описал

(29) набор данных то один, если что.... так что нет там ничего "разительно отличающегося"

(31) "200 000 записей о 30 колонках"?.. и что вы таки после этого хотите? как правило бабу? :) Этот отчет ни кому не нужен, если он не в фискально-контролирующие органы предъявляется (это единственный потребитель бессмысленных отчетов в этой стране).
Попробуй просто создать ТабличныйДокумент такого размера без СКД, думаю, одноэска так же обосрецца.

(33) к этому набору пристёгиваются характеристики и возможно другие наборы, если есть соединение наборов

вообще, забавно, как реляционные базы данных используются для того, чтобы долго-долго собирать инфу, раскладывая ее по разным таблицам, чтобы потом свалить все в ОДНУ НЕВ...БЕННУЮ ПЛОСКУЮ хреноту, которую потом пытаться круть-верть ее в экселе...

(0) пробовал в консоли запускать свой запрос на СКД?

(35)зачем раками душу дразнишь?)

(37) на самом деле раки - не самая вкусная закусь :)

(34) набор данных один, характеристик нет, скомпонованный запрос отличается только подстановкой отборов
(35) это точно! сам поражаюсь таким желаниям :))))))))))))
(36) пробовал, писал уже выше об этом

туплю, при чем тут раки? :))))

(39) ну, скажи, что для того, чтобы получить этот отчет, нужен комп с x64 архитектурой, ибо только на таком компе аппликухи могут получить достаточное количество рамы для "200 000 записей с 30 колонками". Кстати, а распечатывать это оне не собираются?
(40) фотка в ЛК Лефмихалыч

(41) - распечатывать? :)))))))))))))))
на win7x64 клиентская часть 8.1 будет работать? если сервер приложений на х32?

(41) по поводу распечатки - печатать не пытались, но сохранить в ехель - да, ехель 2007 естессно подвис колом тоже :)))))))

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

Все настройки СКД, заслуживающие внимания в студию

(45) прочитайте топик с начала

(45) читай (31)

Не вижу ... А ты пробовал 1) таблицы по отдельности выводить по 1 штуке  и 2) баловаться группировками, выводить их не по 4, а по 2-3 штуки?

(47) прочитал

(49) а, ну тогда ладно

(48) еще раз: рисуем простейшую схему, запрос по регистру из 1000 записей, помноженному сам на себя (left join), на выходе 1 000 000 записей, клиентская часть падает из-за нехватки памяти.

(31) - отключи расшифровку
(51) - безумие выводить 1 млн. пользователю

(51) а накуа?

(52) первый дельный совет! :) убрал расшифровку - памяти хватило :)
но естессно полностью согласен, что отчет в 1 000 000 строк смотреть никто не будет :)

(54) Если несложно пояснить как вы это сделали? У меня такая же проблема с одним отчетом :(

(55)
КомпоновщикМакетаКомпоновкиДанных, у метода Выполнить() третий параметр отвечает за расшифровку данных в СКД

(55) Если надо отключить расшифровку только по конкретному полю, то:
 - переходишь на закладку Макет
 - добавляешь макет поля для ПоляКомпоновкиДанных\
 - указываешь для него ячейку к табличном документе
 - заходишь в свойства ячейки, у свойства "Заполнение" выставляешь значение "параметр"
 - в появившихся дополнительных свойствах, свойство "Параметр" заполняешь  именем поля СКД, в свойство "параметр расшифровки" оставляешь пустым.

(57) благодарю