В практике начинающих разработчиков и администраторов 1С 7.7 часто возникает классическая задача: создать изолированную копию базы данных для тестирования новых возможностей, изменения конфигурации или написания отчетов. Основное требование при этом — не мешать пользователям в рабочей базе и иметь доступ ко всем актуальным накопленным данным (справочникам, документам, регистрам), чтобы не создавать их вручную.
Однако при работе с серверной (SQL) версией платформы 1С 7.7 простая и интуитивная операция копирования папки на диске таит в себе смертельную опасность для работающего бизнеса. В этой статье мы подробно разберем, почему стандартный метод копирования файлов приводит к порче данных в «боевой» базе, как правильно развернуть тестовый контур на MS SQL Server и как безопасно объединить доработки с рабочей конфигурацией.
Рассмотрим ситуацию, с которой столкнулся автор темы. Имея серверную версию 1С 7.7, он скопировал каталог с базой данных в новую папку на диске (например, из C:\1C_Bases\Work в C:\1C_Bases\Test), предполагая, что получил изолированную копию. Но при запуске этой «копии» он фактически продолжил работать с реальными данными компании.
Выясним причину этого поведения. В отличие от файловой версии, где все данные хранятся в DBF-файлах внутри одной папки, SQL-версия 1С 7.7 хранит таблицы данных непосредственно на сервере СУБД (например, MS SQL Server). В каталоге на диске находятся только конфигурация (файл 1cv7.md), словари данных (файл 1cv7.dds), файлы пользователей и служебные файлы.
Связующим звеном между локальной папкой и сервером СУБД является скрытый или системный файл 1Cv7.dba. В нем в зашифрованном виде хранятся параметры подключения к SQL-серверу:
sa) и его пароль.Что происходит при обычном копировании папки?
Когда вы выполняете обычное копирование папки с базой данных средствами Windows, файл 1Cv7.dba переносится на новое место без изменений. Запуская 1С из новой папки, платформа считывает этот файл, видит те же самые учетные данные и незаметно для вас подключается к рабочей базе на SQL-сервере. Любые проведенные документы, удаленные элементы справочников или изменения констант в «тестовой» базе на самом деле физически изменяются прямо в «боевой» базе вашей компании!
В некоторых случаях платформа может выдать ошибку совместного доступа: «Доступ к базе данных на сервере возможен только из одного каталога информационной базы!». Это происходит из-за сверки файла блокировок 1cv7.LCK, но надеяться на эту защиту нельзя — если в базе на тот момент никого не было, платформа без предупреждений пустит вас в рабочую базу под видом тестовой.
---
Чтобы развернуть полноценную и безопасную копию для разработки с сохранением всех данных, необходимо выполнить строго регламентированную последовательность шагов на сервере баз данных и на локальном компьютере.
Шаг 1. Создание резервной копии базы на SQL-сервере
Для начала нам необходимо получить физический снимок данных. Для этого запустим среду управления СУБД (например, MS SQL Server Management Studio — SSMS):
WorkDB)..bak) и запустим процесс архивации.Шаг 2. Развертывание копии базы на SQL-сервере
Теперь создадим новую базу данных на сервере, куда восстановим наши данные:
TestDB..bak)..mdf и .ldf) вели к файлам новой базы TestDB, а не затерли рабочую базу.TestDB, полностью идентичная рабочей по наполнению.Для автоматизации этого процесса на СУБД можно использовать следующий SQL-скрипт:
-- Восстановление тестовой базы из резервной копии рабочей базы
RESTORE DATABASE [TestDB]
FROM DISK = N'C:\Backup\WorkDB.bak'
WITH FILE = 1,
MOVE N'WorkDB_Data' TO N'C:\SQL_Data\TestDB.mdf',
MOVE N'WorkDB_Log' TO N'C:\SQL_Data\TestDB.ldf',
NOUNLOAD, REPLACE, STATS = 10;
Шаг 3. Подготовка каталога на диске для тестовой базы
C:\1C_Bases\Test_Dev.C:\1C_Bases\Work только файл конфигурации 1cv7.md. Файл 1Cv7.dba копировать категорически запрещено!ExtForms и подпапку пользователей usrdef (чтобы перенеслись учетные записи пользователей для авторизации).Шаг 4. Первое подключение и генерация нового файла авторизации
C:\1C_Bases\Test_Dev.TestDB (имя базы, которую мы восстановили на Шаге 2).sa или специально созданный пользователь).1Cv7.dba в каталоге разработки.---
После того как вы провели разработку в тестовой базе, внесли необходимые изменения в структуру метаданных, добавили новые реквизиты или доработали алгоритмы в модулях, наступает этап переноса этих изменений в рабочую базу.
Ни в коем случае нельзя копировать файл конфигурации 1cv7.md из тестовой базы в рабочую напрямую! Это приведет к полной рассинхронизации словаря данных и таблиц СУБД.
Проанализируем правильный алгоритм переноса доработок по шагам:
1cv7.md в архивную папку. Если в процессе обновления что-то пойдет не так (например, отключится электричество), это сохранит работоспособность системы.1cv7.md из нашей тестовой папки (где мы вели разработку).1cv7.dds и выполнит необходимые SQL-запросы ALTER TABLE для изменения структуры реальных таблиц в СУБД.---
Разработчикам, сопровождающим системы на платформе 1С 7.7, необходимо знать о двух ключевых проблемах, которые могут парализовать работу предприятия при обновлении:
1. Попытка ручной замены файлов (.md и .dds)
В кругах администраторов существует вредный миф, что если изменения коснулись только кода модулей (без изменения структуры таблиц, добавления новых реквизитов, справочников или документов), то можно просто скопировать файл 1cv7.md из теста в рабочую базу поверх старого. Действительно, в редких случаях это может сработать, но делать так крайне опасно. Если вы случайно забыли, что в тесте был добавлен хотя бы один скрытый реквизит или изменена длина текстового поля, ручная замена файлов приведет к мгновенному разрушению базы данных (Database Corruption) при первой же транзакции пользователей. База перестанет открываться, выдавая ошибки несоответствия словаря данных.
2. Длительная реструктуризация больших таблиц
Платформа 1С 7.7 использует устаревшие и неэффективные алгоритмы изменения структуры таблиц на SQL-сервере. Если вы в тестовой базе добавили новый реквизит в крупный справочник или документ (например, в справочник номенклатуры или журнал подчиненных документов, где содержатся миллионы строк), то при сохранении изменений в рабочей базе платформа не просто выполнит команду добавления колонки. Она начнет построчно, небольшими порциями (обычно по 1000 записей), копировать данные во временную таблицу SQL, а затем переименовывать её.
На базах данных объемом более 20–50 Гигабайт этот процесс может растянуться на много часов или полностью зависнуть из-за переполнения журнала транзакций SQL-сервера (файла .ldf). Поэтому любые изменения структуры метаданных на крупных базах необходимо планировать исключительно на нерабочее время (ночные часы или выходные дни) и детально тестировать время выполнения этой процедуры на тестовой копии.