При обновлении конфигураций 1С, особенно таких крупных как 1С:ERP, можно столкнуться с ситуацией, когда система сообщает о необходимости реструктуризации таблиц базы данных, но стандартный отчет о сравнении объектов не показывает никаких отличий. Это может не только вызывать недоумение, но и приводить к сбоям, особенно при использовании ускоренных механизмов обновления.
Рассмотрим подобный случай на примере обновления 1С:ERP с версии 2.5.8.x, где при реструктуризации появляются "непонятные" изменения в плане видов характеристик СтатьиРасходов и во всех регистрах, где он используется. Выясним, почему так происходит и что с этим делать.
Основная проблема заключается в том, что платформа 1С фиксирует изменения в метаданных, которые не всегда очевидны при визуальном сравнении конфигураций. Платформа анализирует не только то, что мы видим в дереве конфигурации, но и множество внутренних, служебных свойств объектов.
Выделим несколько ключевых причин, по которым платформа может считать объект измененным:
Изменение служебных данных. При обновлении версии платформы или самой конфигурации могут меняться внутренние идентификаторы или свойства объектов метаданных. Эти изменения не отображаются в окне сравнения, но для платформы они являются сигналом о необходимости обновить структуру таблиц в базе данных.
Изменения в зависимых объектах. Это одна из самых частых причин. В нашем случае объект ПланВидовХарактеристик.СтатьиРасходов имеет составной тип значения. Это означает, что его значениями могут быть ссылки на десятки других объектов: справочников, документов, перечислений. Если в процессе обновления хотя бы один из этих зависимых объектов изменился (например, у справочника увеличилась длина кода, или в перечисление добавили новое значение), платформа может посчитать измененным и сам ПВХ. Это, в свою очередь, каскадно отразится на всех регистрах, где используется реквизит с типом Характеристика.СтатьиРасходов.
Обновление Библиотеки стандартных подсистем (БСП). Современные конфигурации 1С активно используют БСП. Обновление библиотеки может затрагивать базовые механизмы, общие типы данных или подсистемы, что также может косвенно вызывать необходимость в реструктуризации таблиц, связанных с этими механизмами.
В рассматриваемом случае в 1С:ERP 2.5 сам по себе справочник статей расходов претерпевал изменения. В него добавлялись новые поля, что является прямым структурным изменением, которое требует реструктуризации таблиц базы данных.
Отдельная проблема, которая возникает из-за "невидимых" изменений, — это сбой ускоренного (производительного) режима реструктуризации. Разберем, как он работает и почему может давать сбой.
Ускоренный механизм реструктуризации (также известный как v2, появился в платформе 8.3.11) призван значительно сократить время обновления баз данных большого объема. Его принцип работы отличается от старого:
ALTER TABLE. Это намного быстрее, особенно при добавлении новых колонок (реквизитов), не требующих сложного преобразования данных.Ключевая особенность и точка отказа этого механизма — использование внешнего Java-процесса для выполнения команд на уровне СУБД. Именно здесь и возникает конфликт, описанный в проблеме: "1С думает, что регистры изменены, а JAVA считает иначе. Или наоборот".
Это означает, что платформа 1С корректно обнаружила необходимость изменений в структуре, но Java-компонент, который должен эти изменения применить в СУБД, по какой-то причине не может этого сделать или неверно интерпретирует текущее состояние таблиц. Это может быть связано с ошибками в самом Java-процессе, его несовместимостью или спецификой изменений в данном релизе конфигурации.
Проблема была воспроизведена на чистой демо-базе 1С:ERP при обновлении с версии 2.5.8.402 на 2.5.8.410 на СУБД MS SQL с включенным производительным режимом реструктуризации. Это подтверждает, что проблема заключается в конкретном релизе конфигурации и его взаимодействии с платформой.
Рассмотрим по шагам, что делать в такой ситуации:
Временно отключить ускоренный режим. Это самый простой способ завершить обновление. Реструктуризация будет выполняться старым, медленным методом, но, скорее всего, пройдет успешно. Для этого перед обновлением конфигурации базы данных снимите флажок "Выполнять реструктуризацию таблиц в производительном режиме".
Проверить настройки Java. Убедитесь, что на сервере 1С:Предприятия корректно указан путь к Java и что разрядность Java (x86 или x64) совпадает с разрядностью процесса сервера 1С.
Обновить платформу и конфигурацию. Часто подобные ошибки исправляются в последующих релизах. Проверьте наличие более свежих версий платформы 1С:Предприятие и конфигурации 1С:ERP. Возможно, установка более нового релиза решит проблему.
Обратиться в техническую поддержку 1С. Поскольку проблема носит характер воспроизводимой ошибки в типовой конфигурации, самым правильным действием будет создание обращения в техподдержку фирмы "1С". При обращении необходимо указать точные версии платформы и конфигурации, тип СУБД и шаги для воспроизведения ошибки.
В итоге, столкнувшись с "невидимыми" изменениями при обновлении, не стоит паниковать. Платформа, скорее всего, права, и изменения действительно есть, просто они связаны с зависимыми или служебными объектами. Основное внимание следует уделить обеспечению корректного выполнения самой процедуры реструктуризации, а в случае системных сбоев — применять обходные пути и сообщать о проблеме разработчикам.