← На главную

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

Разберем природу возникновения этой ошибки, выясним, почему стандартные средства проверки базы данных не помогают, и рассмотрим пошаговые способы восстановления целостности конфигурации.

Почему возникает ошибка и почему не помогают Chdbfl и ТиИ?

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

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

Почему же стандартные инструменты не видят дефекта:

1. Утилита chdbfl.exe проверяет исключительно физическую структуру файла базы данных 1Cv8.1CD (целостность страниц, заголовков и таблиц), но не выполняет валидацию внутреннего содержимого сжатых потоков 1С.
2. Тестирование и исправление (ТиИ) проверяет ссылочную целостность прикладных данных (документов, регистров, справочников) и не выполняет декомпрессию и валидацию всех внутренних потоков метаданных самой конфигурации.
3. Механизм «Сравнить и объединить» при запуске пытается прочитать потоки всех объектов, включая поврежденный, что неминуемо вызывает то же самое исключение.

Способ 1. Замена поврежденной конфигурации через эталонный файл CF (для типовых конфигураций)

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

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

Разберем порядок действий по шагам:

1. Создаем полную резервную копию базы данных (выгрузка в файл .dt или прямое копирование файла 1Cv8.1CD для файловых баз / бэкап СУБД для клиент-серверных).
2. Определяем точный релиз поврежденной базы. Для этого перейдем в меню Справка → О программе (например, релиз 2.0.23.13).
3. Получаем эталонный файл конфигурации. Разворачиваем чистую демонстрационную или пустую базу того же самого релиза из дистрибутива поставщика. В меню открываем Конфигурация → Сохранить конфигурацию в файл... и получаем чистый файл configuration.cf. Если доступна исходная база, файл поставщика можно также сохранить через Конфигурация → Поддержка → Настройка поддержки → Сохранить в файл.
4. Загружаем конфигурацию в поврежденную базу. Открываем поврежденную базу в конфигураторе и переходим в меню Конфигурация → Загрузить конфигурацию из файла..., выбрав сохраненный эталонный .cf.
5. Применяем изменения. Нажимаем Обновить конфигурацию базы данных (клавиша F7) и подтверждаем реструктуризацию.

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

Способ 2. Восстановление метаданных через выгрузку в файлы XML (для нетиповых конфигураций)

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

Рассмотрим порядок решения:

1. Выгружаем метаданные: выполняем команду Конфигурация → Выгрузить конфигурацию в файлы... (или используем пакетный запуск конфигуратора с ключом /DumpConfigToFiles).
2. Локализуем проблемный объект: переходим в полученный каталог выгрузки, находим описание проблемного документа. Если сама форма повреждена, заменяем XML-дескриптор и файлы формы аналогичными файлами из заведомо исправной конфигурации, либо удаляем ссылку на поврежденную форму из XML-манифеста объекта.
3. Загружаем исправленные исходники: выполняем команду Конфигурация → Загрузить конфигурацию из файлов... (параметр /LoadConfigFromFiles).
4. Обновляем конфигурацию базы данных клавишей F7.

Способ 3. Очистка кэша и таблицы незафиксированных изменений

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

Проанализируем сопутствующие действия:

1. Очистка кэша: завершаем все процессы 1cv8.exe и очищаем каталоги кэша пользователя:

   %LocalAppData%\1C\1cv8\

   %AppData%\1C\1cv8\

   а также очищаем системную папку временных файлов %TEMP%.
2. Сброс таблицы незафиксированных изменений: для клиент-серверных баз при возникновении коллизий в несохраненной конфигурации можно сбросить состояние редактирования, выполнив SQL-запрос к СУБД: DELETE FROM CONFIGSAVE; Это возвращает конфигуратор к стабильному состоянию основной конфигурации базы данных, зафиксированному в таблице CONFIG.