Наткнулся на клиента  который купил замечательную(без иронии) программу местного и инфостартовского разработчика по заливке из внешних источников в базу. У клиента возникла проблема при заливке файла из 90000 строк (три колонки) загружается на форму быстро и он доволен но при внесении данных в объекты(в данном случае регистр сведений) инфобазы ему приходится делить файл на 9 кусков ибо пишет что недостаточно памяти на сервере. Хотя памяти на сервере 12гб плюс ССД плюс большие винты и там кроме него никто не  сидит.
Вопрос:
Кто и как решал эту проблему? Я вот только начал. :)

Я, честно, не решал эту проблему :(

(1) Сочувствую Вашей грусти :))

Думаю, что в данном случае речь не про недостаток физической памяти ОЗУ или HDD. Речь про адресное пространство. А, тогда, вариант только один, поменять сервер 1С с 32х на 64х.

(3) там и стоит 64х.

(0)
>>купил замечательную(без иронии)
>>У клиента возникла проблема
Ты уж определись, родной...

(4) Именно сервер 1С, сама программа 64х?

"замечательная"
Или
"проблема"
?

(5) Что поломало твой мозг?

(8)см (7)

(6) вот разбираюсь теперь. вроде ставил 64.

(7) То есть у замечательной программы не может быть проблем?
У замечательного автомобиля не может быть проблем?
У замечательной вещи не может быть проблем?
У замечательного человека не может быть проблем?

(8)Ну как там твой мозг?

(12) Мой в порядке.

(11)Нет.Не может

(10) Вроде или 64х?

(14) Понятно. Вопросов больше не имею.

(16) а как посмотреть если все уже установлено?

(16)Я аообще удивлен что ты тут возник если что:-)

(17) Очень просто. Либо сервер 1С стоит в Program Files (тогда 64х) либо в Program Files (x86) (тогда 32х).

+(19) Или в службе посмотри, откуда запускается

(0)[памяти на сервере 12гб плюс]
это смартафон, а не сервер

взял полстакана попкорна.
Будет интересно. Но не долго

Я бы вообще не решал эту проблему.
Захреначил бы цикл по 10000 строк и всех делов.

(21) )))) все летает. не поверишь

(23) ну оно понятно. просто лезть в чужую обработку лень. буду ставить свою самопалку аналогичную там уже решу.

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

(0) Решаю подобную задачу в обработке, продаваемой на ИС.
Самые тормоза - это вывод прочитанных данных на управляемую форму. Решил, что если данных более тысячи строк, то нечего им делать на форме. Вывожу только часть информации с кнопкой, позволяющий всё же вывести все данные.
Переделал всё на запуск в фоновом задании. Есть много идей, например, автоматически делить файл на порции или глотать его весь и обрабатывать частями... Но нет таких крупных клиентов, на которых можно тестировать. Большинство удовлетворено и так.

Есть покупатели с мега данными и файловыми базами, изредка жалуются на скорость и память, а на просьбу оказать помощь, уходят в глухую оборону и пропадают. У меня есть решение по ускорению обработки на порядок, но оно требует доводки. :-\
Совет ТС - обратиться к разработчику и сформулировать проблему. Это будет полезнее всем. ;)

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

(26) плюс проблема как ты и сказал в битности. завтра все переставлю и проблемы не будет

(29) Вообще-то сервер 64х стоит в два раза дороже, если что

(30) это да...

(0) в чём суть проблемы? Сохраняй сам порциями (с заданным шагом, например по 10000 строк).