Проверка конфигурации 1С: как найти и исправить ошибки

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

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

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

Как запустить проверку конфигурации и что она включает

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

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

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

1. 1
   Сделайте выгрузку базы: Администрирование → Выгрузить информационную базу
2. 2
   Откройте конфигуратор и меню Конфигурация → Проверка конфигурации
3. 3
   Отметьте логическую целостность и проверку модулей со всеми нужными контекстами
4. 4
   Дождитесь завершения и разберите сообщения сверху вниз
5. 5
   Двойным щелчком по ошибке переходите к проблемному месту и исправляйте

Ошибки логической целостности метаданных

Самая частая группа — ссылки на несуществующие объекты. Типичные сообщения: «Объект не найден», «Ссылка на удалённый объект», «Недопустимое значение свойства». Такое происходит, когда справочник, документ или реквизит удалили, но на него остались ссылки в типах других реквизитов, в подписках на события, в критериях отбора или в составе планов обмена.

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

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

Ошибки модулей: синтаксис и контексты исполнения

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

Контекстные ошибки возникают из-за директив компиляции. Процедура с директивой «&НаСервере» не может вызывать методы, доступные только на клиенте, и наоборот. Типичное сообщение — «Процедура или функция с указанным именем не определена», хотя процедура в модуле есть. Проверьте директивы обоих методов и доступность вызываемого метода в нужном контексте.

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

Ошибки после обновления типовой конфигурации

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

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

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

Тестирование и исправление: когда проверки конфигурации недостаточно

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

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

Для файловых баз есть альтернатива — утилита chdbfl.exe из каталога установки платформы. Она проверяет физическую целостность файла 1Cv8.1CD и применяется, когда база вообще не открывается. Работать с ней тоже нужно только по копии файла.

Чем проверять базу

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

Для ошибок структуры и кода. Безопасна, данных не касается, можно запускать в любой момент

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

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

chdbfl.exe

Для файловых баз, которые не открываются. Только по копии файла 1Cv8.1CD

Средства СУБД

Для клиент-серверных баз: проверки целостности штатными инструментами MS SQL или PostgreSQL

Типичные ошибки при исправлении и как проверить результат

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

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

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

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

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

Норма

Окно сообщений пустое при всех нужных контекстах

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

Остались ошибки целостности или компиляции

Обновление конфигурации базы данных

Норма

Выполняется без предупреждений и ошибок

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

Платформа сообщает о невозможности обновления

Запуск базы в режиме предприятия

Норма

База открывается, основные формы работают

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

Ошибки при запуске или открытии форм

Проведение тестового документа

Норма

Документ проводится, движения формируются

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

Ошибки времени выполнения в модулях

FAQ: частые вопросы о проверке конфигурации 1С

Чем отличаются ошибки от предупреждений в результатах проверки?

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

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

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

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

Для файловой базы используйте утилиту chdbfl.exe по копии файла 1Cv8.1CD. Для клиент-серверной — проверьте целостность средствами СУБД и попробуйте восстановить базу из последней выгрузки или резервной копии. Если копий нет, дальнейшие действия лучше доверить специалисту — самостоятельные эксперименты на единственном экземпляре данных могут усугубить повреждения.

Ошибка «Процедура не обнаружена», но процедура есть в модуле. Почему?

Чаще всего несовпадают контексты: вызываемая процедура помечена директивой «&НаКлиенте», а вызов идёт с сервера, или наоборот. Также проверьте, что процедура экспортная (с ключевым словом «Экспорт»), если вызывается из другого модуля, и что у общего модуля установлены нужные флаги доступности.

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

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