Ситуация, когда в распределенной информационной базе (РИБ) внезапно перестают записываться любые объекты — будь то новый Заказ клиента или обычный элемент справочника Номенклатура — является критической. Ошибка часто выглядит неинформативно: «Не удалось записать документ по причине: не удалось записать документ». Это ставит администратора или программиста в тупик, так как стандартное тестирование и исправление базы не всегда дает результат. В данной статье мы разберем причины возникновения этой проблемы и пошагово восстановим работоспособность базы.
Разберем внутренний механизм платформы 1С. В режиме РИБ любая запись объекта (документа, справочника, задачи) выполняется в рамках одной неделимой транзакции, которая включает два этапа:
Если на втором этапе происходит сбой (например, из-за повреждения структуры таблиц регистрации или некорректных правил обмена), платформа откатывает всю транзакцию целиком. В результате мы получаем общее сообщение об ошибке записи, хотя проблема кроется не в самом документе, а в механизмах синхронизации.
Как показывает практика, одной из наиболее вероятных причин является повреждение регистра сведений ПравилаОбменаДанными. В этом регистре хранятся XML-описания правил конвертации, которые используются при регистрации изменений. Рассмотрим алгоритм восстановления, который помог решить проблему:
.xml. Это можно сделать через настройки синхронизации данных.
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
ПравилаОбменаДанными не срабатывает, может потребоваться кратковременное снятие конфигурации с поддержки для удаления регистра как объекта метаданных или использование специализированных обработок для прямой очистки таблиц..cf), выгруженный из центральной базы.ПравилаОбменаДанными.
УзелЦентр = ПланыОбмена.НайтиПоКоду("001"); // Код центрального узла
ПланыОбмена.УстановитьГлавныйУзел(УзелЦентр);
Проанализируем состояние файловой базы на предмет ограничений. В файловом варианте .1CD существует лимит на размер одной таблицы — 4 Гб. Если обмен данными не выполнялся долгое время или произошел сбой, таблицы регистрации изменений (внутренние имена которых оканчиваются на _ChngR) могут достичь этого предела. В этом случае любая попытка записи объекта будет вызывать отказ, так как новая запись в таблицу регистрации физически не может быть помещена.
Выясним, так ли это, с помощью внешней обработки «Регистрация изменений для обмена данными». Если мы видим огромное количество объектов, ожидающих отправки, следует попробовать очистить регистрацию для всех объектов. Это «обнулит» очередь обмена, но позволит базе снова записывать данные.
Если логическая структура базы повреждена, стандартное «Тестирование и исправление» из конфигуратора может не справиться. Рассмотрим применение утилиты chdbfl.exe, которая находится в папке bin установленной платформы:
1Cv8.1CD.chdbfl.exe, укажем путь к файлу базы.Проанализируем отчет: если утилита нашла ошибки в системных таблицах _Params или Config, это могло быть причиной блокировки транзакций записи.
Чтобы окончательно убедиться, что проблема именно в механизмах обмена, попробуем записать объект программно, имитируя режим загрузки данных. Для этого используем простую внешнюю обработку со следующим кодом:
ОбъектДок = Документы.ЗаказКлиента.СоздатьДокумент();
ОбъектДок.Дата = ТекущаяДата();
// Заполнение минимально необходимых реквизитов
ОбъектДок.ОбменДанными.Загрузка = Истина;
Попытка
ОбъектДок.Записать();
Сообщить("Запись успешна в режиме Загрузка = Истина");
Исключение
Сообщить("Ошибка записи: " + ОписаниеОшибки());
КонецПопытки;
Если в режиме ОбменДанными.Загрузка = Истина документ записывается, значит, проблема стопроцентно кроется в прикладном коде (подписки на события, регистрация в РИБ). Если же запись не проходит даже так — проблема в физической целостности файла базы или правах доступа на уровне файловой системы.
Рассмотрим еще несколько важных моментов, которые могут блокировать работу:
*.1cl и *.lcl. Если в базе в данный момент никто не работает, этих файлов быть не должно. Их наличие может свидетельствовать о «фантомных» блокировках таблиц.В завершение отметим, что для файловых баз в режиме РИБ крайне важно регулярно проводить профилактику: выгрузку/загрузку в .dt и проверку утилитой chdbfl.exe, так как они наиболее чувствительны к сбоям электропитания и сетевым разрывам.