Можно сказать первый раз пришлось столкнуться с загрузкой больших объемов на постоянной основе. Соот-но делаю через ФЗ.
Таблица значений (большая) на форме, в которой пользователь будет заполнять какие-то поля по умолчанию.

Далее эту таблицу можно передать
- Т.Выгрузить() напрямую параметров в ФЗ
- РеквизитФормыВЗначение тоже напрямую (так, например, делается в типовой загрузке из файла)
- Положить ТЗ во временное хранилище

Есть также таблица, которую не нужно показывать пользователю. Ее сразу планирую положить в ХЗ и передавать адресом.

А что вам даст помещение таблицы во временное хранилище в плане её обработки фоновым заданием? Как ФЗ её вытащит?

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

Насчет "большого" размер. Сейчас максимально файл экселя 400 тыс строк. Размер самого файла 88 Мб.

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

Вот и вопрос РеквизитФормыВЗначение как делается в типовых это быстро, но может быть затратно по памяти?

А через хранилище, например, может быть медленней, но менее затратно по памяти. Никуда гонять эту таблицу больше не нужно будет. Обработка в одном ФЗ. Ну может несколько потоков (и то не факт).

Может не загоняться и сделать как в типовой через РеквизитФормыВЗначение?

(0)

А зачем здесь РеквизитФормыВЗначение ?

&НаСервере

Процедура ПослатьНаТаблицуЗначений()

    тз = ОченьБольшаяТаблицаНаформе;

    //Что-то делаем  

КонецПроцедуры

(4) потому что таблица на форме. коллекцию я же не могу передать в ФЗ

(5)

&НаСервере

Процедура ПослатьДалекоТаблицуЗначений()
    //Затупил немного
    //!тзКакОбычнаяТаблицаЗначений = ОченьБольшаяТаблицаНаформеКотораяКакКоллекция.Скопировать();
    тзКакОбычнаяТаблицаЗначений = ОченьБольшаяТаблицаНаформеКотораяКакКоллекция.Выгрузить();

    //Лень смотреть
    Сообщить(Строка(типЗнч(ОченьБольшаяТаблицаНаформеКотораяКакКоллекция)));
    Сообщить(Строка(типЗнч(тзКакОбычнаяТаблицаЗначений )));

    //Что-то делаем  

КонецПроцедуры

(0) Если таблицы очень большие - лучше хранить в БД
Если с БД никак (нельзя РС или еще что добавить) можно в СУБД во временных таблицах (в фоновом крутится на МВТ)
Передавать только изменения чтобы не таскать все

(6) скорее всего ошибка будет)
Выгрузить() - чтобы получить ТЗ

(7) не. это изврат какой-то. не для этой задачи.

(9) Тогда передавать через .Выгрузить() и смириться с тормозами

1. Потестировать ТЗ.
2. Если чет подозрительно - писать в РС с отбором по первому Измерению - УникальномуИдентификатору, которое генерится под каждую ТЗ и потом по нему считывать ТЗ в Фоновом и чистишь. Еще в РС можно писать Дату и иногда удалять записи, у которых дата прошлая, так как это мертвые фз.

(11) Понял. Находил какую-то древнюю тему 14го года с обсуждением этой темы. Там было про 12 млн строк.

Тут гораздо меньше. Я думаю остановится передачу ТЗ параметром. Тут же нет сериализации? А при помещении во врем. хранилище как я понял есть?

Получается плохо помещать большие ТЗ во врем. хранилище что ли? У меня там вторая таблица еще больше. Она не для пользователя и чтобы при переходах туда-сюда ее не гонять (а там интерфейс с переходом Вперед-Назад) я ее помещаю.

(0) Помести исходный файл на сервер и работай с ним оттуда.

(13) Так я вроде объяснил что есть часть файла, с которой пользователь должен работать. И вообще сначала анализируем файл (для чего его приходится целиком читать на клиенте), потом пользователь на этом основании производит настройки. И только потом загрузка. Нет автономности. Иначе не было бы таких вопросов.

(13) Всё равно надо на клиент передавать и обратно, чтобы пользователи могли с ней работать.

Иногда хочется чтобы реквизиты и ТЧ обработок были доступны на сервере через язык запросов
Теоретически такое в платформе можно реализовать, как раз через временные таблицы в СУБД
Живущие пока открыта обработка и сеанс

(16) Хм. Зачем тогда всю таблицу отправлять в ФЗ? Почему не отправить деревом структур только отредактированные строки? "400 тыс." Ну, допустим. Навряд ли пользователь за раз тыщ 100 обработает (это если я правильно проэкстрасенсил, чего там происходит с этими строками). Почему не организовать постраничную передачу данных на клиента? Странная история. Ресурсы надо экономить и грамотно балансировать между рантаймом и БД

(17)

Объясните пожалуйста, зачем в этой задаче дерево ?
Зачем в этой задаче массив структур ?

И главное, зачем таблицу значений из (допустим) 100 тыс строк
превращать в массив структур ?

Какова цель и в каком месте будет экономия (и на чём) ?

(18) Так и не надо 100 тыс. Я пытаюсь понять, зачем вообще всё это нужно. Мне стало очень нехорошо уже на стадии ответа про 400 тыс строк. Каков смысл задачи? Если пазл в моей голове сошелся верно, то предлагается загрузить на форму файл экселя с диким количеством строк, пользователь чего-то там тыкает, вся таблица отправляется на сервер для помещения в ФЗ для обработки.

(14) Тогда нет смысла использовать фоновое задание.
Пользователь вчитал файлик, проанализировал и задал некие настройки - посидит 5 минут пока грузится файл (чаю успеет попить).
Если очень надо - запустит параллельно ещё одну 1С и будет работать

20+ А так, то для ФЗ (7) прав, загоняем в менеджер временных таблиц нужные строки и отправляем его в ФЗ
Получим, временную таблицу SQL и работаем в фоне с оной

На запись в РС время нужно, но если строк замного, тогда имеет смысл поработать с ним

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

(22) Например, отбирает пустое подразделение и заполняет оное в строках

(23) одно для всех пустых или вдумчиво изучат каждую строку?

P.S.
Я в детстве ненавидел игру "испорченный телефон".
А похоже зря

(19) Поскольку доступ к телу заказчика ограничен, то тут смысла я не вижу всю чепуху рассказывать которую придумали. Тут аналитики еще не с такой дичью приходят. А выпендриваться и учить уму разуму чужих аналитиков - время не то.

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

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

(0) а зачем нужно ФЗ? Если не веб-клиент, то можно и так сделать. Ну покурят десять секунд, вместо двадцати секунд наблюденмя длительного кота

(27) ФЗ нужно для параллельной обработки в несколько потоков

(20) "запустит параллельно ещё одну 1С и будет работать"
А лицензии на это ты ему купишь?

(0) Для начала пристрелите разработчиков, которые заставляют пользователей работать с очень большой таблицей напрямую. Дальше полюбому фиксация введенных данных (запись или проведение) и только после этого запуск нужного количества фоновых. Зы. Если смотреть типовые то еще перед фоновым запись в регистр "Задания для...""

(30) С большими данными как раз приходится бывает работать
Понятно через отборы

Имхо на месте ТС можно рассмотреть вариант отдельной конфы с нужными метаданными, которая запускается из основной как форма
После завершения в ней работы, данные забираются в основную конфу
Дополнительный обмен данными можно через http-сервисы

Или работы с внешней СУБД (где нужные большие таблички) через ВИД из 1С
Тут все просто, обычный ДинСписок на форме с запросами

(31)+ Эмм а можно ведь уже полностью программно Внешние Источники Данных создавать?
Так банально базу на sqlite поднимаем и крутим в ней что надо

(31) Да можно проще за счет проработки архитектуры:
Ну допустим парсим валбериз/озон или другую мусорную гору.
Везде есть категории/подкатегрии, Созданием предварительный документ на каждую категорию, а лучше категорию + подкатегорию со статусом "разобрать ховно" (уже будет не 400000 строк). Пользователь проходит и ставит галочки где нужно - документ получает статус "разобранное ховно" и делает задание "переработать в золото". Старые документы можно просто чистить.

(33) Как понял ТС очень хочет простой внешней обработкой обойтись
Без записи всех этих 400 тыщ строк из файла экселя в базу

Вот и предлагаю писать их не в основную базу 1С а в нечто внешнее
И работать так же в этом внешнем
Или же обрабатывать данные по сути там, а выборками отображать в интерфейсе

Сразу при загрузке выбрать только нужную(ые) категории из файла экселя тоже вполне вариант
Грузить и работать только с ними да
Затем следующие

(12) Добавьте регистр сведений и не мучайтесь. Помещение в хранилище и тп - затратно по ресурсам, есть ограничения по размеру. Плюс это все сжирает ОЗУ на сервере.

Сейчас можно довольно быстро это все писать \ удалять.
https://infostart.ru/1c/articles/2508120/

Но если у вас 12 млн строк запись и еще больше во вспомогательной, то будьте готовы к блокировкам (если несколько пользователей будут писать туда). Отборы и тп не помогут, т.к. свыше 50к записей заблокируется весь регистр сведений на период записи \ удаления.

(34) Тут грузится прайс запчастей. Все 400 тыс. грузятся. Обновляются как минимум цены. Могу обновляться какие-то реквизиты. Должны создаваться новые позиции (по новым артикулам).

Старые позиции не проблема грузить без взаимодействия с человеком. Новые позициям должны взаимодействовать с человеком, чтобы заполнить обязательные поля. Я конечно преувеличил, что новых может быть 400. По идее должно быть сильно меньше.

(35) Ради этого какие-то регистры создавать - фигня какая-то. (27) Поскольку обработка по времени будет грузить где-то (думаю) от 30 мин до пары часов и запускать ее будет человек, то блокировать интерфейс неправильно. Поэтому работать будет в фоновом задании. Возможно в несколько потоков (тестирование покажет).

Проверил на 8 тыс строк. Передача и просто обход всей таблицы занимает 3 сек. Это просто передача ТЗ как параметра в ФЗ. Так и оставлю - лишь бы не упало по памяти на 400 тыс строк.

И еще раз - я тут не на фикси, где каждую строчку кода можно вылизывать и доводить до ума. Тут проект. У проекта время, бюджет. Сопротивление аналитиков и пользователей (покалеченных САПом). Мне оно надо все эти квесты проходить?

Да я работал на фикси довольно долго. Еще на 7ке. Непосредственный доступ к заказчику (зам. директора), начальнику ИТ и пара-тройка исполнителей. Вот там можно было любую красоту реализовать.

(36) "лишь бы не упало по памяти на 400 тыс строк." - А это уже не твои проблемы. Так и скажешь: хотите обрабатывать большие объёмы, докупите ещё памяти.

(29) Поставь лицензию локально и запускай сколько тебе вздумается 1С без раздачи оных с сервера
Таки, фоновое - откусит лицензию для себя, не?

(38) Помнится ты мне рекомендовал разбивать большую таблицу на таблице по 1000 строк :)

У меня реально Exell файл на 1 млн строк. И с ним надо работать.
  Я использую ТабличнуюЧасть обработки для передачи данных с Клиента на Сервер.
  Памяти конечно все это жрет немерено. Если Exell файл в бинарном формате имеет размер 10 мб. Открывается за 10 сек. В 1С ТаблицаЗначений из этого файла имеет размер 10 гБ и открывается за пару минут

(40) это если процесс обработки валится по памяти, например, на стареньких компахх

(41) А заполняешь таблицу на Сервере или на Клиенте?
Тут момент - при загрузке наКлиенте будут проходить неявные вызовы сервера и включаться тормоза по мере увеличения таблицы

(40) Ну так разные ситуации - если идёт некая автоматическая обработка таблицы, то разбивка и, в некоторых случаях распараллеливание, имеет смысл.
А когда речь идет тупо о передаче с клиента на сервер - то тут, имхо, смысла разбивать никакого нет.

(44) А не надо такие массивы данных с клиента на сервер гонять
Смысла обычно нету

Если в ТЗ миллионы строк - их явно надо хранить в некой базе
Внутри 1С или снаружи уже отдельный вопрос

(43) Можно и на сервере и на клиенте заполнять. Благо в Exell реквизиты либо число либо строка.
   Заполняются данные из Файла EXELL. Потом идем НаСервер и там уже обрабатываем данные

(46) Так это и есть некая база. В которой уже наверно под 1 млрд строк.

(41) Потому что Excel вас обманывает.

Вставьте в каждую ячейку большой текст в миллион ячеек. Удивитесь, но текст будет фигурировать только 1 раз в sharedStrings.xml
А в ячейках на листах будет только на порядковый номер записи из sharedStrings.xml (притом нумерация там не с 0, а с 1 начинается).

(47) ПолеТабличногоДокумента, в нее загружаем Excel файл на клиенте, в процессе редактирования и обработки обходимся без контекстных серверных вызовов, нажимаем кнопку "Обработать", на клиенте записываем ТабДок в ПотокВПамяти, отправляем поток во внеконтекстный серверный вызов, там восстанавливаем в ТабДок на сервере, обрабатываем его.

ПередЗакрытием очищаем ТабДок на клиенте.

(50) Не надо) Лучше уж в JSON прогнать с табличного документа и передать на сервер.

(50) На сколько я понимаю при чтении Exell файла НаКлиенте в ТабличнуюЧасть не происходит Серверных вызовов. Когда ты переходишь на сервер, то идет всего один серверный  вызов. где передается вся ТабличнаяЧасть

(51) JSON c ТабличногоДокумента в 100 тыс. строк. Это серьезно

(53) если сжать предварительно - не так уж и много. JSON хорошо сжимается zip-ом

(53) Ну хотя да, долго сохраняет ТабДок в JSON.
Можно как вариант ТабДокумент сохранить в Excel и потом на сервере прочитать сразу в ТаблицуЗначений:
https://infostart.ru/1c/articles/225624/

(50) Интересная идея
Причем данные для выбора/заполнения прочитанного ТабДок можно &НаСервереБезКонтекста дернуть с сервера разом или в процессе

Да и обрабатывать перебором строки можно прямо на клиенте, не нагружая сервер
Но код на клиенте будет выглядеть странно, сплошная работа и поиск по массивам/структурам/соответствиям

(56) Так проблема в 1С то что ТабличныйДокумент даже если он пустой, сожрет неглядя 90Гб ОЗУ.
Неоптимальная работа с ним, могу даже примеры обработки скинуть на 1 млн строк, просто выводишь ТабличныйДокумент и гоняешь с клиента на сервер - полная жопа. Данных нет, ОЗУ сожрано на сервере в ноль, все пользователи стоят раком.

(41) Примерно вот такая ситуация. Я хз что там в 1С курят, могли бы уже этот момент оптимизировать и не выделять ОЗУ под пустые ячейки. Все-таки ТабличныйДокумент по-сути Отче наш, на нем все крутится. Весь учет по-сути это вывод печатных формы на выходе или выгрузка в АПИ, налоговую, ФСС и тд.
Притом с выгрузками и АПИ все в целом чет движется, а ТабличныйДокумент извините положили разрабы платформы большой и жирный Х...Й

(57) Пофиг на ТабДок
Суть в идее
Можно ПолеHTML использовать вместо ТабДок

Или если большой ТабДок жрет много RAM то использовать маленький по размеру экрана
И данные обновлять из массивов при "прокрутке" ))

БСП ТаблицаЗначенийВМассив и передать массив. Было?

(57) Не используй табдокумент. Используй таблицу. Так-то табдокумент в первую очередь предназначен для вывода на печать, а не для редактирования таблиц.

(60)

Кусок ОЗУ нарежется как-то более по другому ? (таки да)
Байты скукожатся или что ?

(61) Так это были этикетки для печати по товарам  с 60 тыс. марками ЧЗ. Искал причину, в итоге даже пустой ТабДок столько ОЗУ и съедало плюс-минус.
В итоге сделал вывод таких больших заказов в pdf файлы + склейка в единый файл.

(62) разные объекты, разная работа с памятью. Из-за ТЗ утечки памяти есть, из-за массивов нет. Но у тебя скукожился это да.

(55) А если применить нерекомендуемое ЗначениеВСтрокуВнутр для сериализации при передаче? Оно должно быть быстрее JSON.