← На главную

Ситуация, когда база 1С продолжает работать, позволяет обновлять конфигурацию и проводить документы, но наотрез отказывается выгружать информационную базу в файл .dt, — типичный признак логического или физического повреждения структуры файла .1CD. Чаще всего ошибка звучит как «Таблица не найдена» (например, _InfoRg10398). Это означает, что в системных таблицах базы (таких как DBSchema) запись о существовании объекта есть, а физическое местоположение данных или заголовок таблицы повреждены.

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

Метод 1. Исправление структуры таблицы через HEX-редактор и Tool_1CD

Этот способ считается «хирургическим» и требует понимания внутренней структуры 1С. Основная сложность заключается в том, что в разных информационных базах одной и той же конфигурации имена таблиц хранения (например, InfoRg8568 и InfoRg10398) могут отличаться, так как их номера присваиваются платформой последовательно при создании объектов.

Разберем по шагам алгоритм восстановления:

1. Для начала выясним, какому объекту метаданных соответствует «битое» имя. Для этого в конфигураторе воспользуемся методом ПолучитьСтруктуруХраненияБазыДанных(). Это позволит нам понять, что, например, InfoRg10398 — это регистр сведений ОтветыНаЗапросыВыпискиИзЕГРЮЛ_ЕГРИП.
2. Создадим новую пустую базу того же релиза конфигурации. В ней найдем аналогичную таблицу. Скорее всего, ее номер будет другим (например, InfoRg8568).
3. С помощью утилиты Tool_1CD выполним экспорт этой таблицы из чистой базы в файл. Мы получим два ключевых файла: файл данных и файл описания descr.
4. Теперь нам необходимо «подменить» идентификаторы. Откроем файл описания в HEX-редакторе. Важно понимать, что обычный «Блокнот» использовать нельзя, так как он некорректно обрабатывает символ 00h (нулевой байт), который критически важен для структуры 1С.
5. Проанализируем ситуацию: если длина старого имени (8568 — 4 знака) меньше нового (10398 — 5 знаков), нам нужно «раздвинуть» файл. Рассмотрим, как это сделать с помощью редактора FAR Manager:
   • Используем встроенный редактор FAR, который позволяет вставлять символы, не удаляя нулевые байты.
   • Поскольку кодировка в файле двухбайтная (UTF-16), после каждого добавленного символа нужно вставлять техническую заглушку (например, звездочку *).
   • Затем в HEX-редакторе заменим все звездочки на 00h.
6. После того как имена таблицы и всех ее полей (например, Fld8569 на Fld10399) приведены в соответствие с битой базой, воспользуемся кнопкой «Импорт и создание таблиц» в утилите Tool_1CD для загрузки исправленной структуры в поврежденную базу.

Метод 2. Удаление и пересоздание объекта через Конфигуратор

Если данные в поврежденной таблице не представляют критической ценности (как в случае с регистром ответов на запросы ЕГРЮЛ), самым надежным и простым способом будет полное пересоздание объекта метаданных. Однако обычное удаление может привести к «вылету» конфигуратора. Рассмотрим правильную последовательность действий:

1. Обязательно создаем копию файла .1CD простым копированием в операционной системе.
2. Заходим в конфигуратор и сохраняем конфигурацию поставщика в файл .cf (меню «Конфигурация» — «Поддержка» — «Настройка поддержки» — «Сохранить в файл»).
3. Снимаем базу с поддержки: «Включить возможность изменения», затем «Снять с поддержки». Это позволит нам манипулировать объектами, которые раньше были закрыты «замочком».
4. Находим проблемный объект (в нашем примере — РегистрСведений.ОтветыНаЗапросыВыпискиИзЕГРЮЛ_ЕГРИП) и удаляем его из дерева метаданных.
5. Выполняем обновление конфигурации базы данных (клавиша F7). Если реструктуризация прошла успешно, значит, «фантомная» запись о таблице удалена из системной таблицы DBSchema.
6. Теперь возвращаем объект на место. Для этого выбираем «Конфигурация» — «Загрузить конфигурацию из файла» и указываем ранее сохраненный .cf. При вопросе о постановке на поддержку отвечаем утвердительно.
7. Снова нажимаем F7. Платформа увидит новый объект и создаст для него чистую физическую таблицу в файле .1CD с правильными индексами и полями.

Метод 3. Использование механизма РИБ для «фильтрации» повреждений

Рассмотрим ситуацию, когда стандартное Тестирование и исправление (ТиИ) или утилита chdbfl.exe не справляются, выдавая критическую ошибку. В некоторых случаях помогает механизм создания Распределенной Информационной Базы (РИБ).

Посмотрим на этот процесс подробнее: при создании начального образа подчиненного узла РИБ платформа 1С выполняет глубокое чтение всех объектов и их перенос в новую базу. Если повреждение таблицы носит физический характер (битые сектора внутри файла), механизм выгрузки может «пропустить» поврежденные записи или создать чистую таблицу в новой базе. После успешного создания подчиненной базы ее можно «отвязать» от главного узла, выполнив в коде команду:

ПланыОбмена.УстановитьГлавныйУзел(Неопределено);

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

Почему возникают такие ошибки и как их предотвратить?

Проанализируем причины, по которым база становится «битой». В 90% случаев это происходит из-за динамического обновления («обновление демона»). Когда пользователи находятся в базе, а администратор нажимает «Принять изменения», структура DBSchema обновляется, но старые кэшированные описания таблиц могут остаться в памяти. В какой-то момент это приводит к рассинхронизации идентификаторов.

Важные рекомендации по обслуживанию:

• Никогда не делайте динамическое обновление, если в конфигурации меняются объекты, затрагивающие структуру хранения данных (реквизиты, регистры, справочники).
• Если база достигла размера 4–6 Гб, рассмотрите возможность перехода на клиент-серверный вариант (SQL). В файловом варианте .1CD лимит на размер одной таблицы составляет 4 Гб, и приближение к этому порогу часто вызывает ошибки СУБД.
• Регулярно делайте копии не только через .dt, но и путем прямого копирования файла .1CD. Как мы выяснили, поврежденная база может не дать сделать .dt, и вы останетесь без актуального бэкапа.
• Для конвертации баз между версиями платформы (например, из 8.3.8 в 8.2.14 для работы со старыми утилитами) используйте штатную утилиту cnvdbfl.exe, которая входит в комплект поставки платформы.

Подводя итог, можно сказать, что восстановление «битой» таблицы — это процесс восстановления соответствия между описанием объекта в метаданных и физическим наличием таблицы в структуре 1CD. Используя Tool_1CD для импорта структуры или метод удаления/восстановления объекта, вы сможете вернуть базе работоспособность и успешно выполнить долгожданную выгрузку данных.