При работе с распределенными информационными базами (УРИБ) в 1С:Предприятии 7.7 системные администраторы и программисты часто сталкиваются с ситуацией, когда штатный процесс выгрузки данных из периферийной базы в центральную (или наоборот) внезапно прерывается. Основные симптомы проблемы: файл обмена 1cv77chs.dat начинает стремительно «пухнуть», достигая размеров в несколько гигабайт (иногда превышая размер самой базы), после чего программа закрывается с критической ошибкой Runtime Error. Разберем детально причины этого поведения и способы его устранения.
Первым делом проанализируем содержимое самого файла обмена. Несмотря на то, что он имеет расширение .dat, внутри он представляет собой текстовый поток данных в специфическом формате 1С. Если вы откроете этот файл текстовым редактором (для больших файлов лучше использовать специализированные инструменты типа AkelPad или просмотрщики в Total Commander), вы можете заметить повторяющиеся блоки данных. Проанализируем типичную строку из такого файла:
{"983727|E14",20211216,"0|Мcф",0,0,0,18.18}
Если одна и та же запись повторяется бесконечно, это означает, что механизм выгрузки «зациклился» на конкретном объекте. Выясним причину этого сбоя. В 1С 7.7 процесс формирования выгрузки происходит в оперативной памяти. Когда платформа встречает очень сложный или огромный объект (например, документ с десятками тысяч строк), она пытается сериализовать его в текстовый вид. Если объем данных превышает доступные лимиты памяти для 32-битного приложения (около 2 Гб), происходит сбой указателя записи, и система начинает писать одни и те же данные по кругу до тех пор, пока не произойдет окончательный крах процесса 1cv7.exe.
Для того чтобы исправить ситуацию, нам нужно понять, какой именно документ или элемент справочника вызывает сбой. В строке выгрузки мы видим идентификатор 983727 и префикс базы E14. Рассмотрим подробнее, как перевести эти данные в понятный для 1С вид.
Платформа 1С 7.7 использует 36-ричную систему счисления для хранения ID объектов. Это позволяет записывать большие числа короткими строками, используя цифры от 0 до 9 и латинские буквы от A до Z. Нам необходимо конвертировать десятичное число 983727 в 36-ричную систему. Проделаем расчет:
983727 превращается в L31R.Полный внутренний идентификатор объекта в базе (ID) состоит из 13 символов. Для документов это обычно 9 символов самого ID и 3 символа префикса базы, где объект был создан. В нашем случае объект будет иметь вид " L31RE14" (пробелы в начале важны, так как ID должен иметь фиксированную длину). Теперь мы можем найти этот объект в базе, используя прямой запрос к таблице журналов 1sjourn или программно через встроенный язык.
Разберем пример кода, который поможет нам быстро определить, что это за объект, зная его 36-ричный ID:
// Пример функции для поиска документа по ID
Процедура НайтиПроблемныйОбъект(НужныйИдентификатор)
Док = СоздатьОбъект("Документ");
Если Док.НайтиПоНомеру(НужныйИдентификатор, 0) = 1 Тогда
Сообщить("Найден документ: " + Док.Вид() + " № " + Док.НомерДок);
Иначе
// Если это не документ, ищем в справочниках
Сообщить("Объект с ID " + НужныйИдентификатор + " не является документом.");
КонецЕсли;
КонецПроцедуры
Чаще всего виновником оказывается документ с огромным количеством строк (табличной частью). В 1С 7.7 существует негласное правило: не создавать документы более чем на 9999 строк. При превышении этого порога механизмы УРИБ, проведения и пересчета итогов начинают работать нестабильно.
Рассмотрим несколько вариантов решения, если мы обнаружили документ (например, «Приказ на цены»), в котором содержится 13 000 и более строк.
Это самый правильный метод с точки зрения архитектуры данных. Нам необходимо программно разделить один гигантский документ на несколько мелких (например, по 1000 строк в каждом). Проанализируем алгоритм:
После этой операции обмен пройдет успешно, так как каждый маленький документ будет выгружаться как отдельный блок данных, не перегружая оперативную память.
Если документ критически важен в текущем виде и вы не можете его изменить, можно заставить систему «забыть» о том, что его нужно выгружать. Для этого используется работа с таблицей регистраций изменений _1SUPDTS. Проанализируем ситуацию: 1С хранит в этой таблице записи обо всех измененных объектах, которые еще не были отправлены в другие базы.
Чтобы исключить объект из обмена, воспользуемся методом ВыбратьИзменения() или специализированными обработками для управления регистрацией. После снятия с регистрации файл 1cv77chs.dat перестанет расти, так как проблемный объект просто не попадет в выгрузку.
Иногда причиной зацикливания может быть не размер документа, а повреждение индексного файла таблицы обновлений. Если стандартные методы не помогают, выполним следующие шаги:
.cdx в каталоге базы данных и запустите 1С в монопольном режиме для их восстановления.1supdts.dbf (предварительно сделав бэкап!). Это приведет к тому, что текущие изменения не улетят в другие базы, и вам придется делать «полную выгрузку» или синхронизировать данные вручную, но это поможет восстановить работоспособность самого механизма обмена.Важное примечание: При работе с файловыми версиями 1С 7.7 всегда следите за размером оперативной памяти. Помните, что платформа была разработана в эпоху, когда объемы данных были значительно меньше, и современные «тяжелые» документы — это испытание, к которому ядро версии 7.7 не всегда готово. Разберем и проанализируем структуру данных до того, как они станут критическими, чтобы избежать подобных Runtime ошибок в будущем.