Собственно, ситуация с сабжем: бухия 2 для Казахстана, центральная база 150 Гб, клиент-сервер, платформа 8.2.17.169, нестандартный план обмена, в филиале склеил ласты компьютер с периферийной базой порядка 5 Гб объемом.
Выгрузка начального образа длилась около полутора суток, после чего благополучно вывалилась в Visual C runtime error.

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

Есть ли резон начинать экспериментировать с формированием начального образа на другом сервере с обновленной платформой или не париться и искать альтернативные варианты решения? Может, кто сталкивался с аналогичной проблемой?

З.Ы. Сделать периферийную базу из копии центральной не предлагать - вариант самый крайний и дурной.

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

(0) встречный вопрос : если всё так долго - может взять бекап периферийной базы  , не важно сколько дней давности , и прогрузить туда данные , может это быстрее ?

(2) С бэкапом засада - его, во-первых, никто не делал (мол, зачем периферию бэкапить), во-вторых, даже если бы был, бухи сейчас активно задним числом работают.
(1) Есть подозрение, что такая зачистка базы займет неприемлемое время. Как альтернативу сейчас рассматриваю выборочную регистрацию движений по бух. регистрам (небольшими кусками), чтобы не пытаться все 2.5х2 млн. движений гуртом выгружать.

А может, все-таки кто-нибудь внимательно ченджлоги по последним релизам 8.2 читал и что-то видел, к этой проблеме относящееся?

(3) не используй стандартное удаление помеченных - растянется на века
используй альтернативные механизмы

Книга знаний: Альтернативное создание начального образа в УРБД

можно взять cf  и создатьпустую базу. А все что нужно перенести через выгрузку-загрузку

(5) Это-то понятно, там план обмена сильно нетипичный и фильтрация разных объектов по совершенно разным реквизитам ведется при обмене, еще и по ряду условий. Т.е. на каждый объект, участвующий в обмене, ручками придется фильтр лепить для удаления. Неприемлемость - в объемах ручной работы, проще тогда уж отгрузить все доки без движений, затем порционно движения. Но это я хочу пробовать, если стандартные способы себя исчерпают.
(6) См. пункт "З.Ы." в (0)
(7) Да в курсе, что можно. Но нужно ли? Плевать, что штатными средствами долго выгружается - пусть хоть неделю тарахтит, лишь бы результат был. Вопрос в том, будет ли результат, если платформу обновить?

(8) Будет ли результат - этого тебе никто не скажет

+(8) Да, ошибка не случайная, а систематическая, выгружать пробовали дважды В РАЗНЫЕ филиалы, оба раза через примерно равный промежуток времени вываливалось в runtime error.

(9) А вдрух кто натыкался на аналогичное, народу-то тут много с опытом всякоразным.