Каждый опытный специалист по внедрению и сопровождению программных продуктов на платформе «1С:Предприятие» хотя бы раз сталкивался с ситуацией, когда конфигурация базы данных обновлялась нештатными методами. Наиболее распространенная ошибка неквалифицированных специалистов — накатывание новых релизов путем простого сравнения и объединения файлов конфигурации .cf без выполнения процедуры полноценного обновления поддержки.
В результате таких действий возникает опасный «рассинхрон»: основная конфигурация базы данных фактически соответствует новому релизу, в то время как конфигурация поставщика (информация о поддержке) застревает на старой версии. Например, версия конфигурации базы данных может быть актуальной (допустим, 3.0.25.1), а версия конфигурации поставщика в окне поддержки отображается как устаревшая (например, 3.0.19.3). Это приводит к тому, что последующие штатные обновления становятся невозможными: платформа «не видит» доступных обновлений, выдает ошибки при попытке сопоставить объекты или начинает некорректно отображать дважды измененные объекты.
В этой статье мы подробно разберем, как исправить эту проблему несколькими надежными способами, проанализируем внутренние механизмы сопоставления объектов платформы и выясним, как избежать подобных ситуаций в будущем.
Для начала разберем причину возникновения проблемы. Платформа «1С:Предприятие» хранит внутри информационной базы три конфигурации:
Когда «обновлятор» делает простое сравнение-объединение с файлом .cf нового релиза, он заменяет код и объекты в основной конфигурации, но конфигурация поставщика при этом не обновляется. База формально начинает работать на новом коде, но механизм поддержки считает, что конфигурация всё еще находится на старом релизе. При попытке следующего штатного обновления платформа попытается обновить базу с версии поставщика, которая безнадежно отстала, что вызовет лавину конфликтов метаданных, дублирование предопределенных элементов и критические ошибки СУБД.
Если конфигурация базы данных фактически соответствует актуальному релизу (все объекты обновлены, формы перерисованы, модули актуальны), но отстает только версия поддержки, мы можем обновить конфигурацию поставщика в один шаг, минуя долгую цепочку промежуточных обновлений. Этот метод хорош тем, что мы не затрагиваем измененные нами объекты и не рискуем потерять доработки.
Разберем этот процесс по шагам:
.cf точно того же релиза, до которого фактически доведена основная конфигурация (в нашем примере это релиз 3.0.25.1). Обратите внимание: нужен именно полный файл конфигурации поставщика (типовой .cf), а не файл обновления .cfu..cf релиза 3.0.25.1.Проанализируем, что произошло в этот момент. Так как все флажки объединения были сняты, платформа не изменила ни одного объекта в нашей основной конфигурации (все наши доработки остались в целости и сохранности). Однако платформа обновила саму конфигурацию поставщика до версии 3.0.25.1 и прописала эту версию в качестве текущей. Теперь основная конфигурация и конфигурация поставщика синхронизированы по версиям, и дальнейшие обновления можно проводить в штатном режиме.
Иногда при использовании первого метода платформа отказывается выполнять операцию, выдавая ошибки вида: «На удаляемый объект Подсистема.ИнтернетПоддержкаПользователей... есть ссылки в объектах основной конфигурации». Это происходит из-за того, что в старой конфигурации поставщика структура объектов сильно отличалась, и платформа пытается сопоставить их некорректно. В этом случае применим метод полного пересоздания связи с поддержкой.
Выполним следующие шаги:
.cf нужного нам актуального релиза (например, 3.0.25.1).custom_work.cf)..cf актуального релиза.custom_work.cf, чтобы убедиться, что все наши уникальные изменения на месте.Этот способ считается самым чистым с технической точки зрения и гарантирует стопроцентное избавление от «мусора» в метаданных и битых ссылок в конфигурации поставщика. Рекомендуется использовать его при серьезных расхождениях в структуре метаданных.
Рассмотрим алгоритм реализации этого метода:
corrupted_work.cf).corrupted_work.cf. При этом платформа перенесет все наши измененные объекты, формы, модули и реквизиты в новую конфигурацию, сохранив при этом идеальную структуру конфигурации поставщика.perfect_final.cf.perfect_final.cf.Важное предупреждение: Метод «Загрузить конфигурацию из файла» (F7) в рабочую базу безопасен только в том случае, если исходная конфигурация perfect_final.cf была получена на основе той же самой базы или путем корректного сопоставления объектов. Если уникальные идентификаторы (UUID) предопределенных объектов или реквизитов в загружаемом файле разойдутся с идентификаторами в физических таблицах СУБД рабочей базы, платформа при обновлении базы данных сотрет старые колонки/таблицы и создаст новые пустые. Это приведет к безвозвратной потере данных. Поэтому перед загрузкой конфигурации всегда проводите детальное сравнение загружаемого файла .cf с конфигурацией рабочей базы данных!
Давайте проанализируем, почему возникают риски потери данных при операциях сравнения, объединения и загрузки конфигурации. Платформа «1С:Предприятие» использует три уровня сопоставления метаданных:
Поэтому, если предыдущие «обновляторы» добавляли новые объекты вручную, копированием или простым переносом без сохранения поддержки, их UUID гарантированно отличаются от оригинальных UUID в типовой конфигурации поставщика. При попытке вернуть базу на поддержку всегда контролируйте сопоставление таких объектов, чтобы не допустить дублирования или очистки данных в базе.
Даже если технически вам удалось успешно обновить конфигурацию поставщика в один шаг с древнего релиза на самый актуальный, существует колоссальная опасность потерять учетные данные пользователей в режиме «1С:Предприятие». Речь идет об обработчиках обновления данных.
В процессе развития конфигураций разработчики 1С часто меняют структуру хранения данных. Например, они могут принять решение перенести данные из регистра сведений ПределыВычетовНДФЛ в новый регистр ПараметрыВычетовНДФЛ, а старый регистр переименовать в УдалитьПределыВычетовНДФЛ. Этот процесс всегда разделен на этапы:
Удалить... полностью вырезается из метаданных конфигурации.Если вы обновите конфигурацию базы данных сразу с релиза N-1 до релиза N+5 «в один шаг», минуя промежуточные запуски предприятия, то база данных сразу получит структуру релиза N+5, в которой старого регистра уже просто нет в метаданных (он физически удалится при обновлении ИБ). При запуске программы обработчики обновления попытаются запуститься, но они не найдут источник данных для переноса. Итог — полная потеря истории по данному разделу учета.
Правило: Накатывать конфигурацию поставщика в один шаг можно только для восстановления поддержки, если сама база данных уже была до этого фактически обновлена до нужного релиза последовательно. Если же вы обновляете базу с реальными данными со старого релиза на новый, вы обязаны последовательно проходить ключевые релизы и запускать базу в режиме «Предприятие» для выполнения всех отложенных обработчиков обновления данных.
Чтобы раз и навсегда избавить себя от мучений с обновлением измененных конфигураций и «криворуких» предшественников, настоятельно рекомендуется использовать механизм Расширений конфигурации (файлы .cfe), который активно развивается в платформе 1С, начиная с версии 8.3.9.
Вместо того чтобы снимать конфигурацию с поддержки, разрешать изменения и внедрять свой код непосредственно в типовые модули:
При таком подходе типовая база данных обновляется полностью автоматически одной кнопкой, так как код поставщика остается абсолютно нетронутым. Расширение просто динамически проецируется на структуру базы данных при запуске программы. Это исключает человеческий фактор при обновлениях и сводит стоимость поддержки кастомизированной базы к минимуму.