В практике поддержки старых систем на платформе 1С:Предприятие 7.7 иногда возникают нетривиальные задачи, связанные с "горячим" обменом данными. Одной из таких задач является физическое копирование файлов таблиц (*.dbf) из одной информационной базы в другую. Это позволяет мгновенно синхронизировать справочники без написания сложных обработок выгрузки. Однако, как только структура справочников начинает различаться хотя бы на один реквизит, система выдает ошибки целостности, а ручное добавление полей не помогает из-за несовпадения внутренних идентификаторов. Рассмотрим, как решить эту проблему и добиться полной идентичности структур.
В системе 1С 7.7 имена полей в физических таблицах DBF формируются не по именам реквизитов, которые мы видим в конфигураторе, а на основе внутренних идентификаторов. Например, реквизит "Изготовитель" в одной базе может называться SP8807, а в другой — SP5773. Эти номера (ID) генерируются системой автоматически по порядку создания объектов в конфигурации. Если в Базе 1 до создания реквизита уже было создано 8806 объектов, а в Базе 2 — только 5772, то при добавлении одного и того же реквизита его физические имена в таблицах никогда не совпадут.
При попытке скопировать файл 1Сv7.dbf из одной базы в другую система обнаружит несоответствие словаря данных (файла 1Cv7.DD) и физической структуры файла, что приведет к ошибкам "Не сходится количество полей" или "Словарь данных не соответствует конфигурации". Проанализируем, как обойти это ограничение.
Для того чтобы 1С считала справочники идентичными, нам необходимо принудительно назначить новому реквизиту во второй базе тот же ID, который он имеет в первой базе. Поскольку конфигуратор не позволяет редактировать внутренние идентификаторы напрямую, мы воспользуемся специализированным инструментарием.
Основным инструментом для решения этой задачи является утилита GComp (Global Decompiler/Compiler). Она позволяет разложить бинарный файл 1Cv7.MD на набор текстовых файлов, которые можно редактировать в любом текстовом редакторе.
1Cv7.DD (или 1Cv7.DDS для SQL-версии) в Базе 1. Найдем там описание нашего справочника и нужного реквизита. Выпишем его идентификатор, например, 8807.
gcomp.exe -d -i "C:\Base2\1Cv7.MD" -o "C:\Base2\Unpacked"
Metadata). Найдем строку, соответствующую нашему реквизиту, и заменим его текущий ID (например, 5773) на целевой 8807.
gcomp.exe -c -i "C:\Base2\Unpacked" -o "C:\Base2\1Cv7_new.MD"
1Cv7.MD в Базе 2 на новый. При первом запуске конфигуратора в монопольном режиме система предложит обновить структуру данных. 1С увидит, что реквизит теперь имеет другой идентификатор, и внесет изменения в файл 1Cv7.DD.Важно помнить, что замена DBF-файла "на горячую" — это только половина дела. Вместе с файлом данных .dbf необходимо учитывать файл индексов .cdx. Рассмотрим основные правила:
.dbf, то при открытии базы в 1С мы рискуем получить ошибки или некорректную выборку данных, так как старый индексный файл будет ссылаться на несуществующие позиции записей.SC123.CDX) при каждой замене DBF-файла. При обращении к справочнику 1С сама пересоздаст индекс, если это происходит в монопольном режиме, либо потребуется запуск процедуры "Тестирование и исправление" (ТиС).Если метод с правкой MD кажется слишком рискованным, разберем более "цивилизованные" способы, которые также позволяют добиться результата без ручного ввода данных:
Вместо копирования файлов можно программно подключиться из одной базы к другой и перенести только измененные элементы. Это медленнее, но безопаснее для целостности данных. Выясним, как это выглядит в коде:
// Пример подключения к Базе 2 из Базы 1
База2 = СоздатьОбъект("V77.Application");
ПутьКБазе = "C:\Bases\Base2";
Пользователь = "Admin";
Пароль = "";
Если База2.Initialize(База2.RMTrade, "/d" + ПутьКБазе + " /n" + Пользователь + " /p" + Пароль, "NO_SPLASH_SHOW") = 0 Тогда
Предупреждение("Ошибка подключения!");
КонецЕсли;
СпрОле = База2.CreateObject("Справочник.Материалы");
// Далее следует логика поиска и копирования данных
Для версий 1С 7.7, работающих на MS SQL Server, отличным решением будет использование внешней компоненты 1cpp.dll. Это позволит выполнять INSERT или UPDATE запросы напрямую из одной таблицы в другую, игнорируя объектную модель конфигуратора, но при этом соблюдая типы данных. В этом случае даже несовпадение имен полей SPxxxx легко обходится простым переименованием колонок в теле SQL-запроса.
Проанализировав проблему, мы пришли к выводу, что для полной идентичности справочников в 1С 7.7 необходимо обеспечить совпадение внутренних 36-ричных идентификаторов объектов метаданных. Использование GComp является наиболее эффективным способом "подгонки" структуры одной базы под другую для обеспечения возможности прямого копирования DBF-файлов. Однако всегда следует помнить о необходимости переиндексации и потенциальных конфликтах ID (уникальных кодов элементов), которые могут возникнуть при неконтролируемом смешивании данных из разных источников.