Как проверить конфигурацию 1С на ошибки

Проверка конфигурации 1С на ошибки — обязательный этап как после доработки типового решения, так и при подозрении на сбои в работе базы. Платформа 1С:Предприятие предоставляет несколько уровней контроля: встроенную проверку конфигурации в конфигураторе, синтаксический контроль модулей, тестирование и исправление информационной базы, а также проверку логической целостности данных. Каждый инструмент решает свою задачу, и последовательное их применение позволяет выявить большинство проблем до того, как они проявятся у пользователей.

Ошибки в конфигурации делятся на три категории: синтаксические (некорректный код модулей), структурные (нарушения в метаданных, ссылках, индексах) и логические (некорректные данные, «битые» ссылки, нарушенная целостность регистров). Для каждой категории существует свой механизм проверки, и важно понимать, какой инструмент запускать в конкретной ситуации.

Перед любыми проверками, особенно с включённым режимом исправления, сделайте резервную копию базы. Для файловой базы достаточно скопировать каталог с файлом 1Cv8.1CD, для клиент-серверной — выполнить выгрузку в dt через конфигуратор или средствами СУБД.

Встроенная проверка конфигурации в конфигураторе

Главный инструмент разработчика — команда «Конфигурация → Проверка конфигурации». Она анализирует метаданные и модули без запуска базы и выявляет ошибки ещё на этапе разработки. В окне настроек проверки доступно несколько групп тестов, которые можно включать независимо.

Ключевые режимы проверки:

• Синтаксический контроль модулей — проверяет корректность кода встроенного языка для разных режимов (тонкий клиент, веб-клиент, сервер, внешнее соединение);
• Проверка логической целостности конфигурации — находит ссылки на несуществующие объекты, некорректные типы, ошибки в составе подсистем;
• Проверка правописания — контроль орфографии в синонимах и текстах;
• Поиск некорректных ссылок — выявляет обращения к удалённым или переименованным объектам метаданных;
• Проверка модулей в разных режимах исполнения — ловит ситуации, когда серверный код вызывается в клиентском контексте и наоборот.

Результаты выводятся в окно сообщений. Двойной щелчок по строке ошибки открывает проблемный объект или место в модуле. Исправляйте ошибки сверху вниз: одна ошибка в метаданных часто порождает десяток связанных сообщений в модулях.

1. 1
   Откройте базу в конфигураторе под пользователем с правами администратора
2. 2
   Выполните «Конфигурация → Открыть конфигурацию» и дождитесь загрузки
3. 3
   Выберите «Конфигурация → Проверка конфигурации»
4. 4
   Отметьте нужные режимы: синтаксический контроль, логическая целостность, поиск некорректных ссылок
5. 5
   Нажмите «ОК» и дождитесь завершения анализа
6. 6
   Разберите сообщения об ошибках, начиная с метаданных, затем модули
7. 7
   Повторите проверку после исправлений — новых ошибок быть не должно

Синтаксический контроль модулей и расширенная проверка

Отдельно от полной проверки конфигурации работает синтаксический контроль открытого модуля — кнопка с «галочкой» на панели инструментов редактора или команда контекстного меню. Это быстрый способ убедиться, что текущий модуль компилируется без ошибок, не запуская проверку всей конфигурации.

В настройках конфигуратора доступна расширенная проверка модулей (через «Сервис → Параметры» или флажки в окне проверки конфигурации). Она выполняет более глубокий анализ: проверяет типы передаваемых параметров, существование вызываемых методов, корректность обращений к реквизитам объектов. Расширенная проверка работает заметно медленнее, но находит ошибки, которые обычный синтаксический контроль пропускает — например, обращение к реквизиту, которого нет в объекте конкретного вида.

Обратите внимание на проверку модулей в разных средах исполнения. Код, корректный для толстого клиента, может не компилироваться на сервере или в веб-клиенте из-за недоступности модальных методов, работы с файловой системой или COM-объектов. Включайте в проверку все режимы, в которых реально работает ваша база.

Тестирование и исправление информационной базы

Для проверки самой базы данных используется утилита «Тестирование и исправление» — меню «Администрирование → Тестирование и исправление информационной базы». Инструмент работает только в монопольном режиме: все пользователи должны выйти из базы.

Доступные проверки:

• Реиндексация таблиц — перестраивает индексы, устраняет проблемы с производительностью и некоторые ошибки чтения;
• Проверка логической целостности — проверяет соответствие данных структуре метаданных, находит и исправляет нарушения;
• Проверка ссылочной целостности — выявляет ссылки на несуществующие объекты («битые» ссылки);
• Пересчёт итогов — восстанавливает итоги регистров накопления и бухгалтерии;
• Сжатие таблиц — физическое сжатие файла базы (только для файлового варианта);
• Реструктуризация таблиц — пересоздание таблиц по текущей структуре метаданных.

В нижней части окна выбирается режим: «Тестирование» (только диагностика) или «Тестирование и исправление» (с автоматическим устранением найденных проблем). Первый запуск всегда выполняйте в режиме только тестирования, чтобы оценить масштаб проблем без риска изменить данные.

Проверка физической целостности файловой базы через chdbfl.exe

Если файловая база не открывается, выдаёт ошибки формата потока или «Файл базы данных повреждён», стандартное тестирование в конфигураторе может быть недоступно. В этом случае используется утилита chdbfl.exe из каталога bin установленной платформы.

Порядок работы: скопируйте файл 1Cv8.1CD в отдельный каталог, запустите chdbfl.exe, укажите путь к файлу базы, отметьте флажок «Исправлять обнаруженные ошибки» и нажмите «Выполнить». Утилита проверяет физическую структуру файла: сигнатуры страниц, целостность таблиц, цепочки свободных блоков.

После работы chdbfl.exe обязательно запустите тестирование и исправление в конфигураторе: физическое восстановление часто оставляет логические нарушения — потерянные записи, битые ссылки, сбитые итоги. Полный цикл восстановления выглядит так: chdbfl.exe → тестирование и исправление → контрольная проверка данных пользователями.

Ошибки физической целостности файловой базы чаще всего появляются после внезапного отключения питания, разрыва сети при работе по сетевому диску или сбоев диска. Если такие ошибки повторяются, проверяйте не только базу, но и оборудование: дисковую подсистему, сеть и источник бесперебойного питания.

Поиск и удаление «битых» ссылок

«Битые» ссылки — ссылки на удалённые объекты — типичная проблема баз с большой историей. Они проявляются как «Объект не найден» в отчётах и документах. Проверка ссылочной целостности в «Тестировании и исправлении» находит такие ссылки, однако её действие по умолчанию — очистка ссылок или создание заглушек — не всегда желательно.

Для контролируемой работы с битыми ссылками удобнее использовать типовую обработку «Поиск и удаление дублей» или специализированные обработки поиска битых ссылок из состава БСП-совместимых конфигураций (раздел «Администрирование → Обслуживание»). Они показывают список проблемных мест и позволяют решить по каждому случаю: восстановить объект, заменить ссылку или очистить её.

Помните, что массовая очистка битых ссылок меняет данные прошлых периодов. Если битая ссылка находится в закрытом отчётном периоде, согласуйте исправление с ответственными за учёт — изменение документов может потребовать перепроведения и пересчёта итогов.

Автоматизированная проверка и типичные ошибки

В крупных проектах проверку конфигурации автоматизируют: выгрузка конфигурации в файлы и анализ через EDT, SonarQube с плагином для встроенного языка 1С, запуск конфигуратора в пакетном режиме с ключом проверки. Это позволяет контролировать качество кода при каждом изменении, а не перед релизом.

Пример запуска синтаксической проверки из командной строки:

"C:\Program Files\1cv8\<версия>\bin\1cv8.exe" DESIGNER /F"D:\Bases\Test" /N"Админ" /CheckConfig -ConfigForThinClient

Как убедиться, что база исправна

Контрольные точки

Как проверить результат

Проверка конфигурации

Норма

Окно сообщений пустое или содержит только некритичные предупреждения

Тревожный признак

Ошибки компиляции модулей, ссылки на несуществующие объекты

Тестирование и исправление

Норма

Протокол завершён без строк об обнаруженных ошибках

Тревожный признак

Сообщения о нарушении целостности, исправленных или неисправимых ошибках

Работа пользователей

Норма

Документы проводятся, отчёты формируются без сообщений «Объект не найден»

Тревожный признак

Ошибки при проведении, битые ссылки в отчётах, падение сеансов

Итоги регистров

Норма

Обороты и остатки в отчётах сходятся с ожидаемыми значениями

Тревожный признак

Расхождения остатков, отрицательные итоги без причин

Финальная проверка — не только отсутствие ошибок в протоколах, но и контроль бизнес-показателей. После исправлений сформируйте ключевые отчёты (оборотно-сальдовую ведомость, остатки склада, взаиморасчёты) и сравните их со значениями до начала работ. Совпадение данных подтверждает, что исправления не затронули учётные записи.

Частые вопросы

Как часто нужно проверять конфигурацию и базу на ошибки?

Проверку конфигурации разумно запускать после каждой доработки и перед обновлением релиза. Тестирование и исправление базы — при появлении ошибок, после аварийных завершений и в рамках регламентного обслуживания, например раз в месяц или перед закрытием периода.

Чем отличается проверка конфигурации от тестирования и исправления?

Проверка конфигурации анализирует структуру метаданных и код модулей — то, «как устроена» программа. Тестирование и исправление работает с данными: целостность таблиц, ссылки, итоги регистров. Это дополняющие инструменты, и заменить один другим нельзя.

Можно ли запустить проверку, пока пользователи работают в базе?

Проверку конфигурации — да, она не требует монопольного доступа. Тестирование и исправление — нет: оно требует монопольного режима, поэтому выполняется в нерабочее время или после завершения всех сеансов через консоль кластера.

Что делать, если конфигуратор не открывает базу из-за ошибки?

Для файловой базы используйте chdbfl.exe из каталога платформы — утилита работает с файлом напрямую, без запуска конфигуратора. Для клиент-серверной базы восстановление выполняется средствами СУБД или из резервной копии.

Опасен ли режим «Тестирование и исправление» для данных?

Сам режим тестирования безопасен — он только диагностирует. Режим с исправлением может изменять и удалять данные: очищать битые ссылки, удалять некорректные записи. Поэтому перед ним обязательна резервная копия, а спорные исправления лучше выполнять вручную на копии базы.

Нужно ли проверять расширения конфигурации отдельно?

Да. Расширения проверяются через ту же команду «Проверка конфигурации», когда активно окно расширения. Ошибки в расширении могут блокировать его применение или вызывать сбои в режиме предприятия, поэтому проверяйте расширение после каждого изменения и после обновления основной конфигурации.