Как правильно восстанавливать базу 1С 7.7 на SQL и объединять конфигурации без потери структуры данных?

При совместной работе нескольких программистов с базой данных 1С:Предприятие 7.7 на платформе SQL Server 2008 R2 часто возникает критическая проблема. После восстановления резервной копии (бэкапа) и последующего слияния доработок система начинает выдавать ошибки, указывающие на нарушение структуры таблиц. Пользователи могут сталкиваться с тем, что данные частично или полностью пропадают из интерфейса, а повторное объединение конфигураций лишь усугубляет ситуацию.

В этой статье мы подробно разберем, как устроено хранение данных в SQL-версии 1С 7.7, почему стандартная процедура объединения конфигураций ломает связи между СУБД и метаданными, а также выстроим четкий и безопасный регламент синхронизации баз разработчиков и продакшена.

Разбираем архитектуру хранения данных в 1С 7.7 на SQL Server

Для того чтобы понять природу возникновения ошибок, проанализируем гибридную структуру хранения данных, которую использует платформа 1С 7.7. В отличие от 1С 8.x, где конфигурация полностью упакована внутри СУБД, в «семерке» используются три раздельных компонента, которые должны находиться в абсолютной синхронизации:

1. Файл метаданных 1Cv7.MD. Он располагается непосредственно в каталоге базы данных на диске и содержит описание всех объектов системы (справочников, документов, регистров, реквизитов) и программный код.
2. Файл словаря данных 1Cv7.DDS. Это текстовый файл, который генерируется конфигуратором. Он служит «картой-переводчиком» для платформы, связывая понятные разработчику объекты метаданных с физическими таблицами и колонками в базе данных SQL Server.
3. База данных SQL. Находится под управлением SQL Server и содержит физические таблицы с префиксами SC*** (справочники), DH*** / DT*** (документы), _1SJOURN (общий журнал) и другие.

Рассмотрим пример того, как выглядит сопоставление структуры в файле 1Cv7.DDS:

#====================================================================
# Таблица справочника "Номенклатура"
#====================================================================
[Table]
Name = SC144
Desc = Справочник Номенклатура
Fields = ID, CODE, DESCR, PARENTID, ISFOLDER

Если это соответствие нарушается хотя бы на один символ, платформа теряет связь с таблицами SQL Server.

Почему обычное объединение конфигураций ломает базу данных SQL?

Выясним причину, по которой ломается структура таблиц при параллельной разработке. Главная проблема кроется в механизме генерации внутренних идентификаторов (ID) объектов конфигурации.

Когда вы создаете новый справочник или реквизит, конфигуратор присваивает ему уникальный внутренний ID (например, 144). Соответственно, при сохранении метаданных в SQL-базе создается физическая таблица SC144.

Представим типичную ситуацию работы двух программистов:

1. Программист А в своей локальной копии создает новый справочник «Бренды». Платформа выдает ему очередной свободный ID — 144. На SQL-сервере разработчика А создается таблица SC144.
2. Программист Б в это же время в своей копии создает справочник «Цвета». Платформа также выдает ему свободный ID — 144, так как базы изолированы друг от друга. На SQL-сервере разработчика Б создается таблица SC144.
3. Затем программисты пытаются применить операцию «Объединение конфигураций». При объединении внутренние идентификаторы объектов не синхронизируются автоматически, а переносятся «как есть» или перезаписываются случайным образом.
4. Когда результирующий MD-файл накатывается на базу данных, файл словаря 1Cv7.DDS перезаписывается. Теперь, согласно новому DDS, по идентификатору 144 должны находиться «Цвета».
5. При попытке запустить систему 1С обращается к таблице SC144 в SQL-базе, ожидает увидеть там структуру под «Цвета», но в физической базе данных (которая была восстановлена из бэкапа рабочей базы) под этим ID лежат «Бренды» или структуры вообще не существует. В результате платформа выдает критическую ошибку, а данные не отображаются.

Пошаговый регламент восстановления базы из бэкапа (Вариант А)

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

1. Развертывание СУБД. Восстановите базу данных из резервной копии SQL Server (файл .bak) на сервере разработчика под новым именем.
2. Копирование служебных файлов. Скопируйте файлы 1Cv7.MD и 1Cv7.DDS из каталога рабочей (продакшн) базы данных строго на тот момент времени, когда создавался бэкап SQL. Попытка взять «свежий» MD-файл и соединить его со «старым» бэкапом SQL неизбежно приведет к ошибкам соответствия таблиц.
3. Размещение файлов на сервере разработчика. Поместите скопированные файлы в каталог новой базы на диске разработчика.
4. Первый запуск. Запустите Конфигуратор 1С 7.7 в монопольном режиме для проверки корректности подключения и сопоставления словарей.

Правильный перенос доработок на рабочую базу (Вариант Б)

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

Правильный алгоритм действий выглядит следующим образом:

1. Создание эталонного файла конфигурации. Объединение конфигураций от разных разработчиков выполняйте на абсолютно пустой (шаблонной) базе данных. В результате слияния вы должны получить один финальный «эталонный» файл 1Cv7.MD.
2. Подготовка базы-приемника. Запустите Конфигуратор на целевой базе данных (куда нужно перенести изменения). Перед началом работ обязательно сделайте полную резервную копию файлов 1Cv7.MD, 1Cv7.DDS и бэкап SQL.
3. Загрузка конфигурации (вместо объединения). Перейдите в меню «Конфигурация» — «Загрузить измененную конфигурацию» и выберите ваш финальный эталонный файл 1Cv7.MD. При операции загрузки (в отличие от объединения) платформа полностью заменяет структуру метаданных, сохраняя корректность внутренних ID и не допуская их смещения.
4. Сохранение и реструктуризация. Нажмите кнопку сохранения конфигурации. Платформа 1С самостоятельно проанализирует изменения структуры метаданных, внесет нужные изменения в физическую структуру таблиц на SQL-сервере (добавит новые колонки, создаст таблицы) и автоматически перепишет файл словаря 1Cv7.DDS, сохранив при этом все накопленные данные пользователей.

Критически важные нюансы администрирования 1С 7.7 на SQL 2008 R2

Рассмотрим специфические системные проблемы, с которыми сталкиваются администраторы при обслуживании связки 1С 7.7 и СУБД SQL Server 2008 R2 Express:

Опасность удаления файла 1Cv7.DDS. На профильных форумах часто встречается совет: «Если база выдает ошибку структуры — просто удалите DDS-файл и запустите сохранение конфигурации». Для SQL-версий 1С это действие крайне опасно! Если структура вашего файла 1Cv7.MD уже разошлась с реальным набором таблиц в СУБД, перегенерация DDS-файла «с нуля» заставит 1С обращаться к неверным таблицам. Это может привести к необратимой потере данных или записи информации в чужие таблицы.

Ошибки реструктуризации из-за папки NEW_STRU. При изменении структуры метаданных 1С 7.7 создает в каталоге базы временную директорию NEW_STRU, куда временно складывает преобразуемые таблицы. Если в процессе сохранения произошел сбой (например, отключилось электричество или SQL-сервер выдал ошибку), эта папка останется на диске. Наличие папки NEW_STRU блокирует последующие попытки изменения структуры и запуск базы. Перед повторным запуском обязательно удалите эту папку вручную.

Ограничения редакции SQL Server Express. Версия SQL 2008 R2 Express имеет жесткий лимит на размер базы данных (10 ГБ) и объем используемой оперативной памяти (1 ГБ). Во время реструктуризации больших таблиц 1С 7.7 выполняет тяжелые транзакции. При достижении лимита памяти процесс обновления может аварийно прерваться с ошибкой Out of memory, разрушив структуру базы. В таких ситуациях рекомендуется временно переносить базу на полную редакцию SQL Server для выполнения реструктуризации.

Ошибка порядка сортировки (OrdNoChk.dll). На современных версиях Windows и SQL Server 2008 R2 и выше часто возникает ошибка: «Порядок сортировки, установленный для базы данных, отличается от системного». Для того чтобы обойти это ограничение, выполните следующие шаги:

1. Создайте в каталоге установки платформы 1С (папка BIN) или непосредственно в каталоге базы данных пустой текстовый файл.
2. Переименуйте его в OrdNoChk.dll. Данная библиотека сообщает платформе о необходимости игнорировать проверку кодовой страницы при подключении к SQL.

Резюме для разработчиков

Для того чтобы полностью исключить проблемы слияния кода и структуры таблиц при параллельной разработке в 1С 7.7, мы рекомендуем использовать сторонний инструмент декомпиляции — GComp. Этот инструмент позволяет разбирать файл конфигурации 1Cv7.MD на текстовые файлы классов, модулей и форм, которые затем можно легко помещать в системы контроля версий (Git или SVN). При таком подходе файлы метаданных собираются автоматически без использования штатного «Объединения конфигураций», что навсегда решает проблему конфликтов ID физических таблиц в SQL.