Коллеги, сегодня мы с вами рассмотрим крайне неприятную и, к сожалению, достаточно распространённую ситуацию в работе с платформой 1С:Предприятие, когда стандартные механизмы сравнения и объединения конфигураций не показывают реально существующих отличий. Это может привести к тому, что часть функционала перестаёт работать, а визуальный анализ в Конфигураторе или даже в пользовательском режиме (например, отсутствие кнопок на формах, пропавшие процедуры или функции в модулях) явно указывает на расхождения, которые система упорно игнорирует. Разберёмся, почему это происходит и какие шаги можно предпринять для диагностики и устранения данной проблемы.
Эта проблема затрагивает различные версии платформы 1С, включая 8.2 и 8.3, и может проявляться как при загрузке конфигурации из файла, так и при обновлении из хранилища или сравнении с конфигурацией поставщика. Отсутствие видимых отличий при их фактическом наличии может ввести в заблуждение и значительно усложнить процесс разработки и поддержки систем.
Для начала давайте проанализируем основные причины, по которым платформа 1С может некорректно отображать отличия между конфигурациями или не применять изменения:
Проблемы с кешем 1С. Одной из наиболее частых причин, по которой 1С может некорректно отображать отличия или не применять изменения, является повреждение или устаревание файлов кеша. Кеш представляет собой набор временных файлов, которые 1С создает для ускорения работы, хранения настроек пользователя и конфигурации. Сбои в работе системы, отключение питания или ошибки динамического обновления могут привести к тому, что эти файлы станут неактуальными или поврежденными. В результате 1С может работать с ошибками, отображать неактуальную информацию о конфигурации, или на одном компьютере программа будет работать правильно, а на другом будут появляться необъяснимые ошибки.
Механизмы сравнения и сопоставления объектов. Платформа 1С использует разные алгоритмы сравнения для "произвольных" и "родственных" конфигураций. В случае "родственных" конфигураций (например, при сравнении основной конфигурации с конфигурацией базы данных или конфигурацией хранилища) сопоставление объектов происходит преимущественно по их внутреннему идентификатору, а не по имени. Внутренний идентификатор объекта, как правило, не меняется при выгрузке в файлы формата .cf или .dt и при работе с хранилищем, но всегда изменяется при копировании объекта, в том числе в процессе объединения конфигураций. Если объекты конфигурации были скопированы (например, в результате некорректного объединения или ручного переноса элементов), они могут получить новые идентификаторы. В этом случае механизм сравнения может не увидеть их как измененные версии существующих объектов, а вместо этого воспринять как совершенно новые объекты или вовсе проигнорировать, поскольку соответствие по идентификатору будет утеряно.
Принудительное изменение версии объекта. Опыт коллег показывает, что иногда даже "косметические" изменения, такие как добавление пробела в модуль, могут быть эффективны. Это происходит потому, что 1С определяет измененность объекта по его внутренней версии, а не по фактическому содержимому. Незначительное изменение в объекте может обновить его внутреннюю версию, сигнализируя платформе о наличии изменений и принуждая ее к корректному применению или отображению этих изменений. Это обходит ситуации, когда внутреннее отслеживание изменений платформой может быть рассинхронизировано.
Различие между основной конфигурацией и конфигурацией базы данных. Существует важное различие между конфигурацией, редактируемой разработчиком в Конфигураторе ("Основная конфигурация"), и конфигурацией, фактически хранящейся в информационной базе ("Конфигурация базы данных"). Для того чтобы изменения, внесенные в основную конфигурацию, вступили в силу в рабочей базе, необходимо явно обновить конфигурацию базы данных (например, с помощью клавиши F7 или команды "Обновить конфигурацию базы данных"). Если этот процесс был выполнен некорректно или прерван, это может привести к расхождениям, при которых основная конфигурация и конфигурация базы данных различаются, но эти различия не отображаются корректно при сравнении.
Повреждение объектов метаданных. В некоторых случаях проблема может быть связана с повреждением самого объекта метаданных в конфигурации. Это может проявляться в виде ошибок, таких как "Ошибка формата потока", при попытке сравнения, выгрузки или сохранения конфигурации. Стандартные средства тестирования и исправления информационной базы (например, утилита chdbfl.exe) могут не всегда обнаруживать такие проблемы, поскольку не все объекты конфигурации хранятся в одном месте или подвергаются полной проверке.
Теперь рассмотрим конкретные шаги и обходные пути, которые мы можем предпринять, столкнувшись с данной проблемой:
Прежде всего, всегда начинаем с самого простого и часто эффективного шага – очистки кэша. Поврежденные или устаревшие файлы кеша могут мешать платформе корректно видеть и применять изменения. Мы можем очистить кэш двумя способами:
Ручная очистка кэша:
Открываем проводник и переходим в папки с временными файлами 1С. Обычно это:
%userprofile%\AppData\Roaming\1C\1Cv8\%userprofile%\AppData\Local\1C\1cv8\Внутри этих папок мы обнаружим подпапки с длинными именами, состоящими из букв и цифр. Мы полностью удаляем содержимое этих подпапок. После удаления перезапускаем 1С:Предприятие. Это заставит платформу пересоздать кеш с нуля.
Очистка кэша через удаление базы из списка:
Открываем окно запуска 1С:Предприятия. Находим в списке нашу информационную базу, с которой возникла проблема. Выделяем её и нажимаем кнопку "Удалить". После удаления базы из списка, мы добавляем её заново, указав путь к базе. При повторном добавлении 1С создаст новый кеш для этой базы. Этот метод часто является более надежным, поскольку он гарантирует полное пересоздание кеша, связанного именно с данной информационной базой.
Если очистка кэша не помогла, и сравнение все еще показывает отсутствие отличий, но мы точно знаем, что изменения были внесены, попробуем обновить внутреннюю версию объекта. Это необычный, но часто действенный метод:
Открываем Конфигуратор и находим объект метаданных (например, общий модуль, форму), в котором предположительно были сделаны изменения, но которые не "видны" системой.
Вносим в этот объект минимальное, функционально незначимое изменение. Например, добавляем пробел в комментарии модуля, пустую строку или меняем регистр символа в комментарии. Важно, чтобы это изменение не влияло на логику работы.
Сохраняем конфигурацию (кнопка "Сохранить конфигурацию" или Ctrl+S).
После этого выполняем сравнение конфигураций еще раз. В некоторых случаях это "пробуждает" систему, и она начинает видеть фактические отличия. Если сравнение все еще не видит отличий, но мы подозреваем, что они есть, то переходим к следующему методу.
Когда встроенные средства 1С бессильны, мы вынуждены прибегать к более "ручным", но надежным методам. Один из них — это сравнение выгруженных конфигураций с использованием сторонних программ-компараторов:
Выгружаем конфигурацию из "эталонной" базы (например, из базы, подключенной к хранилищу, где изменения точно есть) в файлы. Для этого в Конфигураторе выбираем "Конфигурация" -> "Сохранить конфигурацию в файлы..." и указываем пустую папку. Платформа выгрузит структуру конфигурации в виде множества XML-файлов и других ресурсов.
Выгружаем конфигурацию из "проблемной" базы (той, куда изменения не применились) точно таким же образом в другую пустую папку.
Используем специализированный софт для сравнения папок и файлов, такой как ComparatorPro, WinMerge, Beyond Compare или аналогичные. Мы указываем этим программам две папки с выгруженными конфигурациями для сравнения.
Внешний компаратор покажет нам все текстовые отличия между файлами, которые соответствуют объектам метаданных. Таким образом, мы сможем точно определить, какие модули, формы, макеты и другие объекты различаются. Этот метод особенно полезен для выявления отличий в общих модулях, модулях объектов, формах и интерфейсах, которые часто игнорируются встроенным сравнением.
После выявления расхождений мы можем вручную перенести недостающие части конфигурации из эталонной базы в проблемную, копируя текст модулей, элементы форм или свойства объектов.
В некоторых случаях, когда сравнение и объединение не работает, а изменения критически важны, коллеги прибегают к прямому использованию команды "Загрузить конфигурацию". Мы должны понимать, что этот метод может быть рискованным, особенно для нетиповых конфигураций на поддержке, поскольку он полностью замещает текущую конфигурацию той, что загружается. Однако, в условиях, когда сравнение показывает отсутствие отличий, а реструктуризация базы данных после загрузки указывает на наличие изменений, этот метод может быть единственным рабочим:
Создаем резервную копию информационной базы! Это критически важный шаг, так как загрузка конфигурации полностью перезаписывает её.
Выгружаем конфигурацию из эталонной базы в файл .cf ("Конфигурация" -> "Сохранить конфигурацию в файл...").
В проблемной базе открываем Конфигуратор и выполняем команду "Конфигурация" -> "Загрузить конфигурацию из файла..." (указываем созданный .cf-файл).
Система запросит подтверждение загрузки. Подтверждаем.
После загрузки, если в конфигурации действительно были изменения, которые система ранее не "видела", платформа предложит "Обновить конфигурацию базы данных" (F7). Если при этом будет выведено сообщение об "Изменении структуры таблиц базы данных" для каких-либо объектов, это будет подтверждением того, что изменения были успешно применены. Проверяем работоспособность функционала.
Имейте в виду, что при таком подходе для конфигураций на поддержке может измениться её статус, и потребуется повторная постановка на поддержку, а также ручной анализ отличий с конфигурацией поставщика.
В тех случаях, когда мы точно знаем, какие конкретные процедуры, функции, команды или элементы форм отсутствуют, и предыдущие методы не принесли результата, мы можем прибегнуть к ручному переносу. Это трудоёмко, но гарантирует результат:
Открываем Конфигуратор эталонной базы и проблемной базы параллельно.
Находим в эталонной базе отсутствующие объекты (например, модуль формы, где должна быть функция, или саму команду на форме).
Копируем (Ctrl+C) или перетаскиваем (drag-and-drop) эти объекты из эталонной конфигурации в соответствующее место в проблемной конфигурации. Например, если отсутствует функция в модуле формы, копируем текст функции. Если отсутствует кнопка, копируем её вместе с обработчиком команды.
Сохраняем изменения и обновляем конфигурацию базы данных (F7).
Этот метод часто использовался коллегами для восстановления работоспособности после подобных аномалий.
Для особо сложных или критических ситуаций, когда необходимо быть абсолютно уверенными в чистоте и правильности конфигурации, мы можем применить более сложный, но надежный процесс, который можно назвать "шаманским" из-за его многоступенчатости:
Создаем полную резервную копию проблемной базы данных в формате .dt ("Конфигурация" -> "Загрузить информационную базу...").
Создаем новую, чистую информационную базу (пустую) в списке баз 1С.
Загружаем в эту новую базу резервную копию, созданную на шаге 1, но не нажимая кнопку обновления ИБ после загрузки (т.е. загружаем только данные без применения конфигурации).
Загружаем в эту же новую базу типовую конфигурацию из файла .cf (или эталонную конфигурацию, которую мы хотим получить), также не нажимая кнопку обновления ИБ после загрузки.
Теперь в Конфигураторе новой базы у нас есть конфигурация, в которую мы можем внести изменения. Сносим (удаляем) в этой новой базе проблемные справочники или объекты, которые, как мы подозреваем, были повреждены или некорректно обновились. Делаем это с осторожностью.
Копируем вручную (копипастом) в неё "правильные" проблемные справочники или объекты из эталонной конфигурации или из только что загруженной типовой конфигурации. Убеждаемся, что все ссылки и зависимости учтены.
Только после всех этих манипуляций нажимаем кнопку обновления информационной базы (F7). Это заставит платформу применить все изменения к данным.
Если все прошло успешно и база работает штатно, выгружаем готовую, исправленную конфигурацию из новой базы в файл .cf.
И только затем загружаем эту проверенную конфигурацию из файла .cf в "боевую" рабочую базу (предварительно сделав её резервную копию!).
Этот метод позволяет "обнулить" проблемные объекты и убедиться, что они будут созданы заново или корректно привязаны к данным.
Иногда проблема может быть связана с конкретной версией платформы 1С. В качестве диагностического шага мы можем попробовать следующее:
Создаем копию проблемной базы.
Открываем эту копию на другой версии платформы (например, если работаем на 8.2.15, пробуем на 8.2.16 или даже на 8.3.10, если конфигурация это поддерживает).
Повторяем попытку сравнения конфигураций. В редких случаях более новая версия платформы может корректнее обработать метаданные и показать отличия.
Если мы работаем с типовой или частично доработанной конфигурацией на поддержке, иногда полезно сравнить основную конфигурацию ИБ с конфигурацией поставщика:
В Конфигураторе выбираем "Конфигурация" -> "Поддержка" -> "Настройка поддержки".
Выбираем опцию "Сравнить, объединить с конфигурацией поставщика".
Это может выявить отличия, которые могли быть внесены или "потеряны" в процессе обновлений, и помочь понять истинное состояние конфигурации относительно типовой.
Важно помнить, что данная проблема является, по всей видимости, одним из "глюков" платформы 1С, который может проявляться при различных условиях. Мы, как разработчики и системные администраторы, должны быть готовы к таким ситуациям и иметь в арсенале несколько методов для их решения. Всегда начинаем с самых простых шагов, таких как очистка кэша, и постепенно переходим к более сложным и трудоёмким, если простые не приносят результата. И самое главное – никогда не забываем про резервное копирование!