← На главную

При аварийном завершении работы, аппаратных сбоях или вирусных атаках (в частности, активности программ-вымогателей и шифровальщиков) пользователи и администраторы баз данных платформы 1С:Предприятие 7.7 нередко сталкиваются с критической ошибкой: «codebase error -200». Данная ошибка свидетельствует о невозможности низкоуровневого чтения таблицы файловой базы данных. Разберем детально, почему возникает эта ошибка, как определить назначение поврежденного файла и какими способами можно восстановить работоспособность информационной базы.

Причины возникновения ошибки CodeBase error -200

В платформе 1С 7.7 для взаимодействия с файлами таблиц DBF и индексными файлами CDX применяется сторонняя библиотека CodeBase. Код ошибки -200 расшифровывается библиотекой как «Not a DBF file» или «Invalid file format».

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

1. Повреждение сигнатуры: первый байт стандартного файла dBase III без memo-полей должен иметь шестнадцатеричное значение 0x03. Если он изменен или зашифрован, файл не опознается как таблица.
2. Сбой в служебных полях заголовка: искажение байтов 8–9 (длина заголовка вместе со списком полей) или байтов 10–11 (длина одной записи данных).
3. Отсутствие байта-терминатора: заголовок таблицы с описанием полей обязательно завершается байтом 0x0D. Если этот маркер затерт, парсер не может определить, где начинаются строки данных.
4. Несовпадение размера: фактический размер файла не соответствует расчетному количеству записей, указанному в заголовке (байты 4–7).

Вирусы-шифровальщики чаще всего шифруют именно начало файла (первые несколько килобайт), затирая заголовок и начальные строки, из-за чего 1С мгновенно блокирует доступ ко всей таблице.

Как узнать, за какой объект отвечает поврежденный файл DBF

Имена таблиц в файловой версии 1С 7.7 формируются платформой автоматически из префиксов и внутренних идентификаторов метаданных (например, DT5716.dbf, DH1420.dbf, SC12.dbf). Чтобы точно понять, какой документ или справочник пострадал, проанализируем структуру базы данных с помощью встроенного словаря данных.

1. Откроем каталог информационной базы.
2. Найдем файл 1CV7.DD (или 1CV7.DDS, если база развернута на SQL-версии). Это текстовый файл, описывающий соответствие внутренних таблиц объектам конфигурации.
3. Откроем файл любым текстовым редактором и выполним поиск по имени поврежденного файла (без расширения), например DT5716.

По префиксам имени файла можно сразу определить тип объекта:

1. DH* (Document Header) — заголовочная часть (шапка) документа.
2. DT* (Document Table) — табличная часть конкретного вида документа.
3. SC* — таблица справочника.
4. CJ* / CR* — таблицы журналов расчетов (в зарплатных конфигурациях).
5. 1CJOURN.dbf — общий журнал документов.

В нашем примере файл DT5716.dbf хранит строки табличной части документа (в конфигурации «Зарплата и Кадры 7.7» это документ БУПроводки — «Формирование проводок»).

Последствия простого удаления файлов DT и CDX

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

1. Нарушение ссылочной целостности: шапки документов в файле DH* и записи в общем журнале 1CJOURN.dbf остаются на месте. Сами документы становятся пустыми — в них полностью пропадает табличная часть.
2. Потеря расчетов: документы перестают формировать движения, либо проводки оказываются рассинхронизированы с итогами.
3. Особенности автосоздания: платформа 1С 7.7 не создает отсутствующие DBF-файлы «на лету» при обычном старте в режиме «Предприятие». Чтобы платформа сгенерировала корректный пустой файл со структурой из метаданных, необходимо обязательно запустить Тестирование и исправление в режиме Конфигуратор с установленной галочкой «Реструктуризация таблиц информационной базы».

Методы восстановления поврежденной таблицы

Рассмотрим по шагам возможные варианты выхода из ситуации в зависимости от масштаба повреждений.

Вариант 1. Переформирование проводок средствами конфигурации

Если повреждена табличная часть документа БУПроводки в конфигурации «Зарплата и Кадры 7.7», ручной ввод данных не требуется. Документ проводок является вторичным:

1. Все первичные расчеты (оклады, премии, больничные, табели) хранятся в журналах расчетов (файлы CJ*, CR*) и кадровых справочниках.
2. Если основные таблицы расчетов не задеты, достаточно отменить проведение поврежденного документа.
3. Запустить штатную регламентную обработку формирования проводок за соответствующий расчетный период и провести документ заново. Табличная часть будет полностью рассчитана и заполнена автоматически.

Вариант 2. Ручная реконструкция файла через HEX-редактор

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

1. Создадим чистый файл нужной структуры. Для этого скопируем файл конфигурации 1CV7.MD и словарь 1CV7.DD в отдельную пустую папку, запустим Конфигуратор и сохраним метаданные. Платформа создаст пустые шаблоны всех DBF-файлов с корректными заголовками.
2. Узнаем точную длину записи таблицы. Откроем файл 1CV7.DD, найдем блок таблицы DT5716 и сложим длины всех полей плюс один байт на метку удаления (байт 0x20 — активная запись, 0x2A — помеченная на удаление). Значение также указывается параметром RecordLength.
3. Откроем поврежденный файл в HEX-редакторе. Найдем границу, где мусорные или зашифрованные байты сменяются осмысленными данными (обычно это видно визуально по повторяющимся пробелам и служебным кодам).
4. Отсчитаем позицию начала целой записи, кратной длине строки данных.
5. Скопируем небитые данные и вставим их в сгенерированный чистый DBF-файл сразу после заголовка (после байта 0x0D).
6. В конце файла данных обязательно установим завершающий символ 0x1A (маркер конца файла DBF).
7. Скорректируем в заголовке нового файла байты 4–7 (общее число записей в формате Little-Endian).
8. Поместим восстановленный файл в каталог рабочей базы, удалим файл индекса DT5716.cdx и запустим базу монопольно для автоматической переиндексации.

Поиск дополнительных источников восстановления

Прежде чем соглашаться на полную потерю части данных, проанализируем систему на наличие скрытых копий:

1. Теневые копии томов (VSS): проверьте состояние службы теневого копирования Windows. Нередко вредоносное ПО не успевает зачистить моментальные снимки на всех локальных дисках.
2. Временные файлы платформы: при активной работе сессий в системных каталогах временных файлов (%TEMP%) или в самой папке базы могут оставаться файлы с расширениями .tmp или .~db, содержащие неповрежденные срезы данных на момент старта программы.
3. Проверка остальных таблиц: если пострадал только один файл, высока вероятность, что в момент атаки он был заблокирован процессом 1С. Однако обязательно выполните тестирование всех остальных таблиц информационной базы, чтобы исключить скрытые повреждения других объектов учета.