← На главную

При сопровождении баз данных на платформе 1С:Предприятие 7.7 (SQL-версия) нередко возникает задача развертывания тестовой копии из рабочей среды. Типичная ситуация: разработчик создает новый вид документа параллельно в рабочей и тестовой базах, после чего делает дамп рабочей базы в Microsoft SQL Server Management Studio (SSMS) и восстанавливает его поверх тестовой СУБД. Однако после запуска тестовой базы новые документы полностью отсутствуют в журналах, хотя в рабочей базе они существуют и заполнены данными.

Разберем детально, почему платформа ведет себя подобным образом, как устроена физическая структура хранения документов в MS SQL и как правильно восстановить тестовую базу без риска повредить боевые данные.

Причина проблемы: архитектура метаданных и внутренние идентификаторы 1С 7.7

Проанализируем внутренние механизмы платформы 1С 7.7. В отличие от более поздних версий платформы, где метаданные и данные хранятся неразрывно внутри единой базы СУБД, в 1С 7.7 конфигурация хранится в файле каталога информационной базы — 1cv7.md, а структура таблиц описана в файле словаря 1cv7.dds.

Когда мы создаем любой новый объект метаданных (документ, справочник, реквизит), платформа автоматически генерирует для него внутренний уникальный идентификатор — ID (в 36-ричной системе счисления):

1. Если создать документ с абсолютно одинаковым названием и реквизитным составом вручную сначала в рабочей базе, а затем в тестовой — платформа присвоит им разные внутренние идентификаторы.
2. Имена физических таблиц в базе данных MS SQL формируются строго на базе этого ID: таблица шапки документа получает имя DH<ID>, таблица табличной части — DT<ID>, а в общем журнале документов _1SJOURN тип документа фиксируется в поле IDDOCDEF.

Когда мы восстановили бэкап рабочей базы на тестовый SQL-сервер, таблицы в СУБД перезаписались и получили идентификаторы из рабочей базы. Но каталог тестовой базы на диске остался прежним: файл 1cv7.md тестовой базы ожидает совершенно другой ID документа. В результате платформа либо обращается к несуществующей таблице, либо не находит в журнале _1SJOURN записей с тем IDDOCDEF, который прописан в локальном 1cv7.md.

Решение проблемы: синхронизация файла метаданных

Для того чтобы тестовая база «увидела» восстановленные из SQL данные, необходимо привести файл конфигурации в строгое соответствие с загруженной структурой таблиц СУБД.

Разберем по шагам правильный алгоритм действий:

1. Скопируем файл конфигурации 1cv7.md из каталога рабочей базы в каталог тестовой базы данных.
2. При необходимости можно скопировать и файл описания структуры 1cv7.dds, однако при первом же сохранении конфигурации платформа перегенерирует его автоматически.
3. Если в рабочей базе менялся список пользователей или их права, перенесем также подкаталог usrdef.

Критически важный шаг: проверка параметров подключения к базе данных

При копировании конфигурационных файлов или всего каталога информационной базы возникает серьезная опасность случайной модификации боевых данных. Настройки подключения к СУБД сохраняются в локальных служебных файлах (в частности, в файле 1cv7.cfg).

Если скопировать файлы и сразу запустить 1С в режиме «Предприятие», программа может подключиться не к тестовой базе SQL, а к рабочей. Пользователи или тестировщики начнут вносить изменения в боевую среду.

Чтобы избежать этой критической ошибки, выполним следующие действия:

1. Запустим тестовую базу исключительно в режиме Конфигуратор.
2. Откроем главное меню: Администрирование — Параметры базы данных.
3. Убедимся, что в поле База данных указано имя именно тестовой базы на SQL-сервере, а не рабочей.
4. Проверим имя SQL-сервера и параметры авторизации пользователя СУБД.
5. Нажмем кнопку Сохранить (значок дискеты) в Конфигураторе. В этот момент платформа синхронизирует метаданные 1cv7.md с SQL-таблицами и сформирует корректный файл словаря 1cv7.dds.

Рекомендации по регламенту разработки в 1С 7.7

Чтобы в будущем не сталкиваться с несовпадением внутренних идентификаторов объектов, придерживаемся следующих правил:

1. Никогда не создавать объекты вручную дважды в разных базах. Разработка нового функционала должна вестись в тестовой конфигурации.
2. Для переноса доработок в рабочую базу используем штатный механизм объединения конфигураций (меню Конфигурация — Объединение конфигураций) либо полную замену файла 1cv7.md при монопольном доступе. Только в этом случае внутренние идентификаторы ID документов и справочников в обеих базах останутся идентичными.
3. Если требуется перенести документы между базами, конфигурации которых уже разошлись по внутренним ID, перенос следует выполнять не через дамп SQL-сервера, а специализированными средствами обмена: универсальными обработками выгрузки/загрузки через текстовые файлы/XML, конфигурацией «Конвертация данных» или через OLE-соединение (V77.Application).