← На главную

Нередко разработчики сталкиваются с крайне неприятной ситуацией: в рабочую базу добавлены новые реквизиты или табличные части, пользователи уже заполнили их данными, но после очередного обновления конфигурации все накопленные сведения бесследно исчезают. Первая мысль, которая возникает в таком случае — отработал фоновый или монопольный обработчик обновления информационной базы, который «причесал» справочник и очистил поля. Однако на практике программный код типовой конфигурации здесь ни при чем. Разберем детально физические механизмы работы платформы 1С:Предприятие, выясним истинную причину проблемы и рассмотрим регламент безопасного обновления.

Внутренние механизмы платформы: почему очищаются данные

Главная причина затирания данных кроется в том, как платформа 1С связывает объекты конфигуратора с физическими таблицами в базе данных СУБД. Платформа идентифицирует таблицы справочников, табличные части и реквизиты не по их строковым именам (синонимам или идентификаторам метаданных), а по внутренним уникальным идентификаторам — UUID (внутренним кодам метаданных).

Рассмотрим, что происходит при типичной ошибке разработчика:

1. В рабочей базе создается реквизит или табличная часть. Платформа генерирует для них уникальный внутренний UUID и создает соответствующие колонки или таблицы в СУБД.
2. Разработчик берет копию базы или отдельный файл конфигурации и добавляет аналогичный реквизит вручную, через буфер обмена (копипастом) или накатывает из другой ветки. При таком создании новому объекту присваивается совершенно другой UUID, даже если имя и тип полностью идентичны.
3. Разработчик применяет операцию «Конфигурация — Загрузить конфигурацию из файла» вместо процедуры объединения.

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

Как распознать опасность до применения изменений

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

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

Пошаговый алгоритм правильного обновления через объединение

Чтобы избежать подмены идентификаторов и сохранить данные пользователей, разберем по шагам корректный регламент применения доработок:

1. Обязательно создаем резервную копию информационной базы перед любыми манипуляциями с метаданными.
2. Открываем конфигуратор рабочей базы и выбираем в меню пункт «Конфигурация — Сравнить, объединить с конфигурацией из файла...» (ни в коем случае не «Загрузить конфигурацию из файла»).
3. Выбираем подготовленный файл .cf. В режиме сравнения и объединения платформа сопоставляет объекты не только по внутренним идентификаторам, но и по именам, сохраняя существующие UUID целевой базы данных.
4. В открывшемся окне сравнения анализируем дерево объектов. Снимаем общую отметку со всех объектов и аккуратно проставляем флаги только напротив тех реквизитов, табличных частей и модулей, которые действительно требуют обновления.
5. Обращаем внимание на шестеренку настройки объединения: проверяем правила соответствия. Убеждаемся, что добавленный реквизит сопоставлен с существующим реквизитом базы, а не отмечен как удаляемый с созданием нового.
6. Выполняем объединение, после чего сохраняем конфигурацию и нажимаем «Обновить конфигурацию базы данных» (F7).
7. В окне реорганизации информации внимательно проверяем список действий: там не должно быть удалений таблиц или очистки колонок с нужными данными.

Важные правила перехода между релизами конфигурации

Если рассматривается обновление типовой конфигурации (например, переход линейки «Управление торговлей» с версии 11.0 на 11.3), важно помнить о правилах межрелизных обновлений. Прямой скачок через несколько промежуточных подверсий категорически недопустим, так как архитектура прикладных решений и Библиотеки стандартных подсистем (БСП) кардинально перерабатывается.

Обновление должно производиться строго по цепочке, рекомендованной фирмой «1С» в файле поставки. На каждом промежуточном релизе необходимо:

1. Корректно накатить файл обновления поставщика (.cfu или .cf) с сохранением пользовательских доработок через сравнение и объединение.
2. Запустить конфигурацию в пользовательском режиме «1С:Предприятие» под учетной записью с административными правами.
3. Дождаться полного завершения всех монопольных и отложенных процедур обновления информационной базы.
4. Только после успешного завершения обработчиков переходить к обновлению на следующий релиз.

Современные альтернативы: как защитить доработки от затирания

Чтобы исключить влияние обновлений типовой конфигурации на доработанный функционал, проанализируем архитектурные механизмы, которые рекомендует платформа:

1. Типовой механизм «Дополнительные реквизиты и сведения»: если требуется добавить простые реквизиты в справочники или документы (например, в карточку номенклатуры), используйте встроенную подсистему свойств БСП. В этом случае изменения вносятся в пользовательском режиме без редактирования конфигуратора, а значения хранятся в отдельных регистрах сведений и гарантированно не затрагиваются никакими реструктуризациями.
2. Механизм расширений конфигурации: современные версии платформы позволяют добавлять собственные реквизиты и табличные части в объекты основной конфигурации через расширения с сохранением данных. При этом основная конфигурация остается на типовой поддержке, обновляется стандартными файлами без риска повреждения пользовательских данных.

Что делать, если данные уже утеряны после реструктуризации

Если реструктуризация базы данных уже завершилась с удалением информации, вернуть данные стандартными средствами текущей базы невозможно — физические записи из таблиц СУБД стерты. Рассмотрим пути восстановления:

1. Восстановление из бэкапа: разворачиваем резервную копию, сделанную до обновления, во временную базу. С помощью типовой обработки «Выгрузка и загрузка данных XML» или написания собственной простой обработки переносим значения потерянных реквизитов и строк табличных частей по связке через ссылку объекта (Ссылка / УникальныйИдентификатор).
2. Восстановление на уровне СУБД: если база работает под управлением клиент-серверной СУБД (например, MS SQL Server) и база находится в модели восстановления Full, можно восстановить базу на момент времени непосредственно перед операцией реструктуризации (Point-in-Time Recovery), после чего выгрузить утраченные данные.