Почему в регистре сведений тип ресурса меняется с перечисления на справочник и как это исправить

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

Анализируем природу проблемы: рассинхронизация метаданных

Прежде всего, разберем внутренние механизмы платформы. 1С хранит описание структуры базы данных в специальных системных таблицах (таких как Config, DBSchema и Params). Каждому типу данных (справочнику, документу, перечислению) присваивается внутренний числовой идентификатор — TypeID. Когда мы сталкиваемся с тем, что перечисление «превращается» в справочник, это верный признак рассинхронизации между конфигурацией, которую видит платформа, и реальной структурой таблиц в SQL-базе.

Выясним основные причины такого поведения:

• Динамическое обновление (так называемое «демоническое»): Это наиболее частая причина. При обновлении конфигурации в режиме предприятия структура таблиц в SQL может обновиться некорректно или частично. В итоге идентификаторы типов в заголовках таблиц начинают указывать на неверные индексы.
• Зависание «фантомных» полей: Если вы меняли состав типов ресурса (например, делали его составным, а потом снова простым), платформа могла не удалить старые типизирующие колонки в SQL. При записи система обращается к одной колонке, а при чтении запросом — к другой.
• Конфликты расширений: Если в расширении конфигурации затронут этот же регистр или используются объекты с похожими именами, может возникнуть конфликт пространств имен.

Шаг 1. Диагностика через консоль запросов

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

ВЫБРАТЬ
    ТИПЗНАЧЕНИЯ(ИмяРегистра.ИмяРесурса) КАК ТипДанных,
    ИмяРегистра.ИмяРесурса КАК ЗначениеРесурса
ИЗ
    РегистрСведений.ИмяРегистра КАК ИмяРегистра

Если запрос возвращает тип, отличный от Перечисление, воспользуемся функцией ВЫРАЗИТЬ. Это поможет нам проверить, сохраняется ли типизация на уровне SQL-запроса:

ВЫБРАТЬ
    ВЫРАЗИТЬ(ИмяРегистра.ИмяРесурса КАК Перечисление.ИмяВашегоПеречисления) КАК Статус
ИЗ
    РегистрСведений.ИмяРегистра КАК ИмяРегистра

Если данный запрос выдает NULL или ошибку, значит, проблема зарыта глубоко в структуре SQL и простое перевыбор типа в конфигураторе не поможет.

Шаг 2. Очистка кеша и тестирование базы (ТИИ)

Прежде чем переходить к радикальным мерам, выполним стандартные процедуры оздоровления базы. Посмотрим на последовательность действий:

1. Очистка локального кеша: Удалим базу из списка и добавим ее заново или вручную очистим папки в %AppData%\1C\1cv8.
2. Очистка серверного кеша: Если база клиент-серверная, необходимо остановить службу 1C:Enterprise Server и удалить содержимое папки snacc в каталоге сеансовых данных. Именно там могут храниться «кривые» скомпилированные описания типов.
3. Тестирование и исправление (ТИИ): Запустим конфигуратор, перейдем в «Администрирование» — «Тестирование и исправление». Обязательно выберем пункты «Реиндексация таблиц» и «Реструктуризация таблиц». Последний пункт особенно важен, так как он заставляет платформу пересоздать физические таблицы SQL на основе текущих метаданных.

Шаг 3. Работа с расширениями и хранилищем

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

Также стоит обратить внимание на Хранилище конфигурации. Если объект был удален и создан заново под тем же именем, у него меняется внутренний UID. Если один разработчик затянул изменения, а у другого в этот момент была открыта старая версия, при помещении в хранилище может возникнуть «разрыв». В таком случае рекомендуется полностью удалить объект из конфигурации, зафиксировать изменения в хранилище, а затем создать его заново.

Шаг 4. Радикальное решение: перезапись структуры

Если стандартное ТИИ и чистка кеша не помогли, воспользуемся проверенным методом «выгрузки-загрузки». Разберем, почему это работает: при выгрузке в файл .dt сохраняются только данные и логическая структура. При последующей загрузке в новую базу платформа создает все таблицы SQL «с нуля», что гарантированно очищает базу от мусорных записей в системных таблицах Params и DBSchema.

Если и это не помогает, или вы не можете сейчас прервать работу пользователей для долгой выгрузки, применим метод «пересоздания объекта»:

1. Создадим новое перечисление (временно) и укажем его в ресурсе регистра.
2. Выполним обновление конфигурации базы данных.
3. Создадим новый ресурс в регистре с правильным типом.
4. Если новый ресурс работает корректно (данные сохраняются и тип не «плывет»), перенесем данные из старого ресурса в новый программно.
5. Удалим старый «сломанный» ресурс.

Шаг 5. Меры предосторожности при работе с SQL

Для опытных администраторов существует путь исправления через SQL Management Studio. Однако помните, что прямое редактирование таблиц 1С лишает вас поддержки вендора. Тем не менее, иногда полезно проверить таблицу _Config на наличие дублирующихся записей о структуре регистра. Если вы видите, что для одного и того же объекта метаданных существует несколько описаний, это подтверждает теорию о сбое при динамическом обновлении.

Подводя итог, можно сказать, что проблема с подменой типа — это всегда следствие некорректного обновления структуры базы. Сочетание очистки серверного кеша (папка snacc), реструктуризации таблиц и, в крайнем случае, пересоздания объекта в конфигураторе позволяет полностью устранить этот неприятный баг.