Приветствую, суть проблемы, начинаю проводить обмен, от уриба в цб, создается файлик, 1cv77chs.dat и размер его пухнет, на текущий момент 3 гб, при общем весе базы 3.20, оставлял этот обмен на ночь, видимо распухается до колосальных размеров и выбивает ошибкой runtime, куда копать, в чем может быть косяк

Причем загрузка отрабатывает и данные от цб заходят, а на выгрузке колом становится

Скопировал файлик этот, поглядел циклирует одну и ту же запись
{"983727|E14",20211216,"0|Мcф",0,0,0,18.18},

1. Как вариант - просто снести все индексы и переиндексироваться.
если не поможет -
2.1. посмотреть, что это за док с идом "  L31RE14", что с ним за проблемы
2.2 как вариант - тупо удалить его из апдейтса, переиндексировать аптдейтс и выгрузить. и уж потом разбираться с доком

(3) Переиндексация не решает, первое что попробовал, а как ты получил L31RE14, если E14 я вижу, откуда приставка родилась?

(3) Вопрос док ли это, а не какой нибудь элемент справочника

(4) 983727 же

(6) это должно быть примитивно?)))

(6) ну поищи в апдейтсе, по тайпид посмотри, что за тип объекта

(7) ?

(9) я не могу понять как 983727 может = L31RE14

(10) как полагается, в 36-ричной системе.
можешь поискать правила перевода, или описание функций _StrToId и _IdToStr, правила формиования идов в 7.7 и все такое.

(10) (983727)10 = (L31R)36, последние три символа в ид - код ИБ создания объекта

(12) E14 это код этой базы, значит иддок L31R получается?

(13) ну русским по белому же написано - получается  "  L31RE14"

(14) Спасибо, нашел в чем косяк

(15) ну так рассказал бы честнОму народу...

(16) есть документ приказ на цены, в нем 13 000 бюстгалтеров, они начинают выгружаться, переполняют оперативку и крашат 1ску

(17) если база файловая, то более 9999 строк в доке не рекомендуется. Но я с файловыми работал мало, поэтому насчет краха не скажу.
ну и оперативка ни при чем.