В процессе эксплуатации информационных баз 1С администраторы и разработчики часто сталкиваются с аномальным поведением системы: при выполнении стандартной процедуры «Тестирование и исправление» (ТиИ) консоль выдает бесконечный список сообщений типа Объект изменен: Документ.КассоваяСмена или Регистрация изменена. Ситуация осложняется тем, что при повторном запуске процедуры картина не меняется, а пользователи жалуются на «мистические» ошибки — например, когда данные в отладчике видны, но в самом документе (например, «Ввоз из ЕАЭС») табличные части остаются пустыми до тех пор, пока не будет сделано несколько циклов реиндексации. Разберем детально причины такого поведения и эффективные методы восстановления работоспособности системы.
Для начала проанализируем, почему 1С выводит эти уведомления. Вопреки опасениям, это не всегда означает наличие критической ошибки в самих данных. Эти записи появляются в режиме реструктуризации таблиц информационной базы.
Рассмотрим основные причины:
Регистрация изменена напрямую связано с механизмом синхронизации данных. Если в конфигурации настроены узлы обмена, система хранит таблицы регистрации для каждого объекта. При повреждении этих таблиц или принудительной проверке ссылочной целостности 1С может перезаписывать эти данные, чтобы гарантировать актуальность обмена. Если записи появляются снова и снова, это признак того, что процесс реструктуризации не доходит до логического завершения из-за блокировок или поврежденных индексов.Перечисления, могут попадать в лог исправлений. Это происходит, если система обнаруживает битые ссылки в объектах, которые используют данные перечисления, или если в таблице перечислений нарушен внутренний порядок идентификаторов.Ситуация, описанная автором темы, крайне показательна: в отладчике данные в табличной части видны (переменная заполнена), но после завершения процедуры создания документа пользователь видит пустую таблицу. И только многократная реиндексация временно спасает положение. Выясним причину этого феномена.
Основная причина здесь кроется в разрушении индексов (Index Corruption). В 1С данные хранятся в физических таблицах, а быстрый доступ к ним обеспечивают индексы. Представим ситуацию: физически запись в таблице существует, но индекс, указывающий на неё, поврежден. Когда программный код выполняет запрос к данным (например, при заполнении на основании), SQL-сервер (или движок файловой базы) обращается к индексу и... не находит соответствия. В результате запрос возвращает «пусто», хотя прямой просмотр объекта в отладчике через ссылку может показывать наличие данных.
Почему помогает реиндексация? Она полностью перестраивает эти вспомогательные таблицы. Однако, если база «сыпется» (есть физические повреждения диска или критические ошибки в структуре файла .1CD), новые записи снова будут создавать кривые индексы, и через короткое время проблема вернется.
Если стандартное ТиИ не помогает, а сообщения об изменениях объектов продолжают появляться, необходимо применить более глубокие методы очистки и восстановления.
Для файловых баз это первое средство спасения. Утилита chdbfl.exe находится в папке bin установленной платформы. В отличие от ТиИ, которое работает на логическом уровне (проверяет ссылки, типы данных), эта утилита проверяет физическую целостность файла базы данных.
Важно: Всегда делайте резервную копию перед запуском этой утилиты!
Если chdbfl.exe находит ошибки и исправляет их, это верный признак того, что индексы и внутренние страницы файла были повреждены. После работы этой программы обязательно нужно запустить ТиИ с флагом «Реиндексация таблиц информационной базы».
Иногда «мистика» с заполнением документов вызвана тем, что на стороне сервера или клиента закэширована старая структура метаданных. Проанализируем, как правильно очистить кэш:
%AppData%\1C\1cv8\.1C:Enterprise Server Administration и очистить содержимое папки reg_1541 (внимательно, не удалите файлы самой базы, если они там лежат!).Если записи «Объект изменен» не пропадают, попробуем метод полной пересборки базы. Выгрузка в файл .dt и последующая загрузка в пустую базу данных — это не просто копирование, а полная пересоздание всех таблиц и индексов с нуля. Это позволяет избавиться от «фантомных» записей в системных таблицах, которые ТиИ может игнорировать.
Если проблема сохраняется даже на «здоровой» базе, нужно убедиться, что дело не в ошибке кода. Рассмотрим пример проверки заполнения:
// В модуле объекта или менеджера при заполнении
// Проверьте, что ТЧ заполняется до момента записи
Если ЗначениеЗаполнено(ДокументОснование) Тогда
// Инициализация данных
ДанныеДляЗаполнения = СформироватьЗапросПоОснованию(ДокументОснование);
// Если здесь ДанныеДляЗаполнения.Количество() > 0,
// а после Загрузить(ДанныеДляЗаполнения) в ТЧ пусто -
// ищите фильтры в ПриЗаписи или ПередЗаписью
ЭтотОбъект.Товары.Загрузить(ДанныеДляЗаполнения);
КонецЕсли;
Если в коде используется Полнотекстовый поиск для подбора данных, проверьте статус индекса полнотекстового поиска. Если он поврежден, это также может приводить к пустым результатам подбора в документах.
Появление бесконечных записей об изменении объектов в ТиИ и проблемы с заполнением — это симптомы деградации структуры базы. Решение задачи требует комплексного подхода: от физической проверки утилитой chdbfl.exe до полного пересоздания базы через выгрузку/загрузку. Не стоит пренебрегать и проверкой кэша, так как 1С часто хранит в нем некорректные планы запросов, которые приводят к «пустым» результатам при наличии данных в таблицах.