Имеется ТЧ в которой около 10000 штрихкодов, нужно их записать в регистр сведений розницы. Если делать это в лоб через менеджер записи загрузка занимает около часа. Как можно оптимизировать загрузку? Можно ли передать в параметры отбора набора записей список номенклатуры для которой будут записываться штрихкоды?

(0) записать не через менеджер записи, а через набор записей

(1) Можно ли передать в параметры отбора набора записей список номенклатуры для которой будут записываться штрихкоды?

(2) вообще без отбора фигачь.

(3) :) и затереть 60000 загруженных ранее записей

(0) >>Имеется ТЧ в которой около 10000
Хочу тебе сказать что у меня РС ШК выгрузка-15 сек и загрузка-<15 сек между разными базами

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

(2) Да.

Да ничего не выйдет

цикл и отбор по каждой номенклатуре в наборе записей..

(9) а разница с циклом и менеджером записи

Нужно просто взять и придумать обьединяющий элемент для всех 10000 и писать с его отбором.

Например, это будет справочник Группы штрих-кодов, идентифицируемый по sha1 хэшу суммы 10000 шк

http://3.bp.blogspot.com/_CmgCLuCWZGQ/S8bv3gZ0zqI/AAAAAAAAAC8/wyIcgXDx5Kw/s1600/Computer+reasons.jpg

Вариант: создать набор без отборов, прочитать, добавить в него загружаемые данные, записать. Может быть и даст прирост в скорости, тут много "но", думать надо.

(4)У Записи есть параметр не затирать.

Ждём результаты тестов от ТС

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

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

(17) Нет, нельзя

Можно отменить транзакцию в попытке

Ну или делай без транзакции, а в попытке формируй список проблемных ШК
Либо вычисли их предварительно в запросе

(17) 10000 записей - это ни о чем, детский размер для регистра сведений. Поэтому вам в другую сторону копать надо. У вас похоже код какой то выполняется, в при записи или перед записью в модуле регистра или в подписках.

(21) вполне возможно. Розница стандартная ред. 2.2, что там может выполняться при записи штрихкода?

Сделай замер, чо

(22) вот если стандартная у вас розница
,  то там по любому в при записи миллион всякого кода - это сто процентов.

(24) как с этим бороться? посмотрел в модулях там есть проверка дублирования кодов, и наверняка в подписках где-то задействовано.

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

точнее не помню, не напишу т.к. сейчас не за рабочим компом и подсмотреть в конфигурации возможности нет.

(25) писать обмен данными.загрузка=истина

(27) Значит, через набор записей

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

(29) У менеджера не нашёл свойство в СП :)