← На главную

Подмена главного файла конфигурации 1cv7.md на файл из другой базы — одна из наиболее опасных ошибок при обслуживании 1С 7.7. В платформе версии 7.7 каждому объекту метаданных (справочнику, документу, реквизиту) назначается уникальный внутренний идентификатор. При прямом копировании MD-файла внутренние идентификаторы метаданных перестают совпадать с реальными названиями колонок и таблиц в файлах данных DBF (или в таблицах MS SQL), из-за чего система выдает критические ошибки вида "Таблица - DT2414. Не сошлось наименование поля номер 19 - SP10470" и блокирует работу.

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

Обязательный шаг перед началом любых работ

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

Способ 1. Поиск сохраненной копии MD в каталоге NewStru и временных папках

Выясним, сохранила ли платформа 1С 7.7 копию оригинального файла перед последним сохранением или объединением конфигураций.

1. Перейдем в каталог информационной базы и проверим наличие папки NewStru. При проведении реструктуризации платформа 1С создаёт этот каталог и сохраняет в нем файл 1cv7.md, который существовал до начала изменений. Если этот файл сохранился, скопируем его с заменой обратно в корень базы.
2. Проанализируем временный каталог пользователя (папка Temp операционной системы). При сохранении конфигурации платформа также может оставлять временные файлы с исходной структурой метаданных.
3. Проверим наличие теневых копий Windows (VSS). В свойствах каталога базы данных или файла 1cv7.md откроем вкладку "Предыдущие версии" и проверим, есть ли точка восстановления, созданная до момента подмены.

Способ 2. Сравнение словарей данных 1cv7.dd и декомпиляция с помощью gcomp

Если оригинальный файл 1cv7.md найти не удалось, но в каталоге базы сохранился старый файл словаря данных 1cv7.dd (или 1cv7.dds для версии SQL), мы можем восстановить соответствие идентификаторов.

Разберем логику работы словаря данных:

Файл 1cv7.dd содержит текстовое описание структуры данных. В нем зафиксированы физические имена таблиц и полей (например, таблица DT2414 и реквизит SP10470) и их связь с объектами метаданных. При наличии старого файла 1cv7.dd и нового словаря, сформированного подмененным MD, проанализируем различия:

1. Откроем старый файл 1cv7.dd текстовым редактором и найдем проблемную таблицу, указанную в ошибке (например, DT2414).
2. Посмотрим, какому реквизиту или полю соответствовал идентификатор SP10470 в исходной базе.
3. Воспользуемся утилитой gcomp для разобранного представления MD-файла. Распакуем подмененный файл 1cv7.md в текстовый формат.
4. В полученных исходных файлах конфигурации исправим внутренние идентификаторы созданных или измененных реквизитов так, чтобы они совпадали с оригинальными названиями полей из старого 1cv7.dd.
5. Собраем MD-файл обратно с помощью gcomp и поместим его в каталог базы.

Способ 3. Принудительная реструктуризация проблемных таблиц через Конфигуратор

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

Проанализируем алгоритм безопасной реструктуризации:

1. Откроем базу в режиме Конфигуратор.
2. Определим по тексту ошибки, в какому объекту принадлежит сбойная таблица (например, таблица DT2414 отвечает за табличную часть конкретного документа).
3. Найдём этот документ в дереве метаданных и добавим в него один временный реквизит любого типа.
4. Сохраним конфигурацию. В этот момент платформа 1С 7.7 запустит процесс реструктуризации именно для этой таблицы и приведет ее физическую структуру DBF в соответствие с текущим MD-файлом.
5. Вернемся в Конфигуратор, удалим ранее созданный временный реквизит и повторно сохраним конфигурацию.

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