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

т.е. это не для клиента. Это если тебе нужно табдок сохранить на сервере, тогда через БСП'шное наружное апи, ты можешь дернуть по пруфу выше, и оно тебе сохранит це на сервере где-то. А что ты с этим дальше будешь делать - решать тебе. Если интересует конкретная реализация, то не экспортная функция ТабличныйДокументВДвоичныеДанные() делает описуемое.

и хотелось бы еще статы: это сколько строк в табдоке что он так фризится? 30 тыс. в осв бухгалтерском - не фризится, скролится нативно, вообще никаких тормозов.

Печать в файл немного не то что мне надо.

я про то же. Это не твой кейс. Через двоичные данные надо гонять табдок, если ты его хочешь сохранить в какой-то формат, и потом - предположим - открыть. Все. Если табдок фризится, как у тебя, при просмотре - то там очевидно, какое-то триллионое количество строк. 30 тысяч - то что есть под рукой - не фризится. Единственная трабла - не сохраяет в эксель под 32-битном клиенте, памяти не хватает. Ставишь 64 и эта проблема тоже уходит. Т.е. наверное тебе там поковырять чота другое стоит.

Формируем отчёт. Жмём ctrl+end, жмём pgup

Было вчера ? )

ссылки на тг группу не было)

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

Да, если включить замер , можно увидеть число строк / 100 количество вызовов сервера в этот момент.

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

Ну у нас большая часть отчётов содержит по несколько десятков тысяч строк и приличное количество колонок ) вообще столкнулся с этим когда мутил фильтры как в Экселе. Получилось неплохо, но остался момент с передачей документа на клиента.

стандартный вопрос - кому и зачем нужны 10 тыщ строк. Кто их смотрит, как? Шапка из фольги там норм сидит у пользователей? :)

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

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

SAPway =)

да в экселе сводными таблицами и формулами из отчетов на 100 000 строк такую магию творят, что в 1С и не снилась

надо начать с того, что для того, чтобы подготовить данные для сводной таблицы, их надо "от вэ-пэ-эрить" из в лучшем случае соседних листов, в худшем - откуда-то с сетевых шар. После этого, когда итоговые датасет все таки появится, вопрос не в том, как сводной таблицей его накрыть - а как проверить полученное. Затем, крутить сводные таблицы в разных "группировках" - это то еще удовольствие. Считать же дельты по типу - сравнение результатов аналогичных периодов из типовых, на сводных - это уже из разряда фантастики. Я видел лично адские вбашные скрипты, которые что-то подобное делали. Мне эта тема знакома, я как раз некоторое время назад автоматизировал все это дерьмо - заливал сырые, не от "вэ-пэ-эринные" данные в 1С, там их валидировал при загрузке, и уже оттуда на скд рисовал "сводные" таблицы. Эффект был - а..ть, а что 1с правда так может :)

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