Собственно такое вот.
Патч ромикса не при делах, дат-файл из зип-выгрузки совпадает с romix.dat, загрузка вылетает абсолютно одинаково с патчем и без него.
А именно.
вылет происходит на одном и том же элементе справочника "Контрагенты".
последние изменения в dbf-файлах: SCXXX, 1SBLOB, 1SCONST
в dat-файле ничего навскидку(!) криминального не нашел.

Логика подсказывает, что все-таки в dat-файле с последним импортированным (или со следующим за ним) контрагентом - проблема.

ПРОШУ ПОМОЩИ.

Что именно может быть перекосячено в дат-файле, как этот косяк нацти и как попробовать исправить?..

А, может быть, объём уже и за 2 Гб перевалил ?

(1): 1св7.дат = 1,6Гб

(2)+: самые большие файл базы данных:
1SENTRY.DBF = 388М
1SACCSEL.CDX = 373М
RA6869.DBF = 315М
1SJOURN.CDX = 304М
RA1173.DBF = 293М
1SJOURN.DBF = 258М
и т.д.

(2) Он же zip-ованый, насколько я помню.

(4): єто уже распакованній.

(5) Тогда странно, что там может быть такого ?
А если вручную разобрать ?

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

(7) Во-первых, именно его, во-вторых, что идёт дальше и нет ли повторения записей (когда две разных записи с одним ID).

(8): нет, сразу следующий контрагент без дублирования ИД.
старт-блок загруженного начинается с {"5201| (и используется до конца блока)
старт-блок следующего начинается с {"5202| (и используется до конца блока)

(9) Тогда проверять длины строк, символы (кодировка может быть другая) и прочие вещи.
Если есть возможность - обрезать файл и грузить частями.
P.S. commit-то выполняется при каждой записи или сразу блоком - я как-то не вникал - возможно, что запись даже не следующая, а через несколько.

(10): "обрезать и грузить частями" - это как?..
(а ТиС должно найти нечитаемое в базе?.. выгрузки-загрузки с такой симптоматикой (один-в-один) и в "тренировочной" бэкап-базе делаются...

(11)+: в "только тестирование". у меня технологически висят пустые ссылки - ни очищать, ни создавать объекты низзя.

А бы попробовал, сначала, вырезать этого и следующего контрагента из файла и посмотреть, что произойдёт.

(13): подскажи, плз, фришный редактор, который бы с таким размером текстовика управится...

ЗЫ: от безысходности нарисовал ert-шку, которая ч/з stream-объект символы из dat-файл в сводную табличку выгонит... хз рпавда получится ли...

(15) Я именно так и делал, так как нормальные редакторы это не умеют. Ну, конечно, можно hiew попробовать, но там только замена.

(15) Через Scripting.TextStream я редактор диска для восстановления данных писал с посекторным редактированием - вот это было "чудо" - тормозное, но работало.

(16): не взлетело. точнее - не дождаться, начальство копітом над ухом бїет - рвется аналитики крутить, а Scripting.TextStream в 1с-ину по-символьно собирать с раскодировкой (и блоками пробовал, и посимвольно, и по-мегабайтно) - ну страаашно медленно. не дождался забил.
убил на тестирование полдня - нашел пустой ИД все-таки (и подчиненных без владельцев, и потомков без родителей - но то в других справочниках и не прерывает загрузку - грузит как есть, а вот на пустом ИД вылетает в "неисправимую ошибку" и алё;
скачал нео-хекс-едитор (триального хватило). выпилил из дат-файла весь блок по элементу с пустым ИД-ом (ссылок не должно было быть, так что поленился ему в дат-файле выписывать "свободный" ИД). упаковал обратно мд+уср+дат винзипом с минимальным сжатием. вроде загружается.
ежели загрузится - спляшу джигу, а с потомками б/родителей и подчиненными б/владельцев потом буду разбираться, в процессе..
спасибо, бро.

(18) Я бы пустой ID заменил на какой-то другой, например, максимально большой.

(19): я бы тоже, но там по всему блоку шариться можно ошибиться, да и "глючный" контр почти наверняка нигде не использовался (иначе бы дало ошибки при тестировании на нулевой эе ид), и к тому же он в справочнике был помечен на удаление, и буквально следующими ид-ом и код-ом (уникальность = весь справочник) шел "нормальный" с тем же наименованием.
сисадмину надо мозги полоскать - наверняка при записи элемента сервак сбойнул.

(20) Записи с нулевым ID система просто не видит.
Вполне возможно, что-то порушилось при транзакции или запись разных секторов в момент закрытия программы.
В общем - не важно как - но появился.
А в базе, где он есть - можно посмотреть ?

(21): таки видит. оба элемента (глюкавый б/ИД-а и следующий такой же но с ИД-ом) - в самом справочнике прекрасно видны, а пометка на удаление одного из них говорит о том, что и обрабатываются нормально.
не видны они только если этот элемент попробовать "получить" из справочника - не возвращает "ТекущийЭлемент()". видно там в форме списка справочника в кишочках все.

(22) В общем, с чьей-то подачи в базу плюнули - а нам копаться и разбираться - ну - в общем - как всегда.

(0) Уже предлагали запустить ТиИ? :)
Убрать из БД текстовые поля неопределенной длинны.

или

нажать на буковку "Я"
http://yandex.ru/yandsearch?rpt=rad&text=1C%20UpDownUplFail;5;%CE%F8%E8%E1%EA%E0%20%E7%E0%E3%F0%F3%E7%EA%E8%20%E4%E0%ED%ED%FB%F5;;&lr=54

(24): Уже предлагали читать прежде чем писать? :)
1) мимо абсолютно (да и совет сам по себе немного, кхм...)
2) что по ссылке после "или" - мимо абсолютно, гугель был перекопан и без того.
в итоге - всё равно спасибо.