В практике администраторов и разработчиков 1С периодически возникает критическая ситуация: после стандартного, казалось бы, обновления конфигурации в автоматическом режиме (через пакетный файл или скрипт) внезапно обнаруживается, что значения некоторых реквизитов в справочниках или документах полностью очистились. При этом внешне конфигурация выглядит корректно, имена реквизитов не менялись, а типы данных остались прежними. Разберем подробно, почему это происходит, как работает механизм сопоставления объектов в платформе и что нужно делать, чтобы не допустить катастрофической потери данных.
Для понимания сути проблемы проанализируем, как платформа 1С «узнает» объекты метаданных. Для человека основным идентификатором является Имя (например, СуммаДокумента). Однако для платформы 1С имя — это лишь строковое свойство, которое можно легко изменить. Внутренним и неизменным ключом объекта является GUID (UUID) — уникальный 128-битный идентификатор.
Рассмотрим стандартный процесс обновления через команду /LoadCfg (Загрузить конфигурацию из файла). В этом режиме платформа полностью заменяет текущую конфигурацию той, что находится в файле .cf. Если в загружаемом файле у реквизита изменился GUID (даже если имя осталось идентичным), 1С трактует это следующим образом:
При выполнении реструктуризации базы данных (/UpdateDBCfg) платформа физически удаляет колонку в SQL-таблице, соответствующую старому идентификатору, и создает новую пустую колонку для нового идентификатора. В итоге данные, накопленные годами, безвозвратно исчезают в процессе выполнения скрипта.
Выясним причины, по которым GUID объекта в файле обновления может перестать совпадать с GUID в рабочей базе данных. Проанализируем основные сценарии:
Особое внимание уделим автоматизации. Использование BAT-файлов для загрузки .cf (команда /LoadCfg) крайне опасно тем, что этот метод по умолчанию не выдает интерактивных предупреждений о потере данных. В обычном режиме (через Конфигуратор) при нажатии кнопки «Обновить конфигурацию базы данных» (F7) 1С вывела бы окно со списком удаляемых полей. В автоматическом режиме скрипт просто выполняет команду, и администратор узнает о проблеме только после жалоб пользователей.
Разберем методы, которые позволяют обезопасить процесс обновления, даже если вы используете автоматизацию.
В современных версиях платформы 8.3 при обновлении конфигурации базы данных через командную строку рекомендуется использовать параметр, который блокирует изменения при наличии предупреждений. Посмотрим на пример команды:
"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /S "Server\Base" /N "Admin" /P "Pass" /LoadCfg "C:\Updates\1c_new.cf" /UpdateDBCfg -WarningsAsErrors
Ключ -WarningsAsErrors заставит платформу прервать процесс, если планируется удаление объектов или реквизитов с данными. Это позволит остановить выполнение батника до того, как SQL-таблицы будут изменены.
Если вы обнаружили, что идентификаторы «поехали», единственный способ спасти данные — это выполнить ручное сопоставление. Проанализируем алгоритм действий:
Для надежного контроля изменений рассмотрим методику сравнения исходных кодов конфигурации. 1С позволяет выгружать метаданные в формат XML. Если перед обновлением выгрузить текущую конфигурацию и новую в папки, можно воспользоваться любой утилитой сравнения текстов (например, WinMerge или встроенное сравнение в IDE). Если вы увидите изменения в файлах, которые не должны были меняться (массовое изменение UUID в файлах описания объектов), значит, конфигурация обновления «битая» и ее нельзя загружать через /LoadCfg.
Рассмотрим применение специализированного ПО, такого как «Обновлятор 1С». Подобные утилиты перед выполнением обновления анализируют список изменений. Если программа видит, что планируется удаление реквизитов в таблицах, где есть данные, она блокирует процесс и уведомляет администратора. Это гораздо безопаснее, чем использовать самописные BAT-скрипты.
Если обновление уже прошло и колонки в SQL очистились, проанализируем варианты восстановления:
.bak средствами SQL прямо перед запуском скрипта обновления.FULL, теоретически можно попытаться извлечь данные из лога транзакций, но это требует экспертных знаний SQL и специализированного софта.COM-соединение или JSON/XML выгрузит значения потерянных реквизитов из старой базы и запишет их в новую. Пример структуры такой обработки:
// Пример логики восстановления реквизита "Статус" для справочника "Контрагенты"
Выборка = Справочники.Контрагенты.Выбрать();
Пока Выборка.Следующий() Цикл
Объект = Выборка.ПолучитьОбъект();
// Получаем значение из резервной копии по ГУИД ссылки
ЗначениеИзКопии = ПолучитьЗначениеИзКопии(Объект.Ссылка.УникальныйИдентификатор());
Если ЗначениеИзКопии <> Неопределено Тогда
Объект.Статус = ЗначениеИзКопии;
Объект.Записать();
КонецЕсли;
КонецЦикла;
Ситуация с потерей данных при загрузке .cf — это классический пример того, как технические особенности платформы (использование GUID) могут привести к бизнес-рискам при недостаточной проверке изменений. Чтобы избежать подобных проблем, всегда придерживайтесь правила: автоматическая загрузка допустима только для типовых конфигураций или полностью проверенных релизов. Для нетиповых решений, где изменения вносятся вручную, предпочтительнее использовать механизм «Сравнить/Объединить» или внедрять строгий контроль идентификаторов через выгрузку в файлы.