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

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

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

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

(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к записей заблокируется весь регистр сведений на период записи \ удаления.