Как исправить ошибку СУБД «поле не найдено Т2._Fld1426RRef» при создании распределенного узла в 1С?

Приветствуем вас! При работе с распределенными информационными базами (РИБ) в среде 1С:Предприятие технические специалисты часто сталкиваются со сложными системными сбоями в момент генерации начального образа подчиненного узла. Одним из наиболее коварных симптомов является аварийное завершение процесса с ошибкой выполнения POST-запроса к ресурсу /e1cib/logform по причине СУБД: «Ошибка SQL: поле не найдено 'Т2._Fld1426RRef'».

В этой статье мы подробно проанализируем природу этого сбоя, выясним, почему стандартные механизмы СУБД дают осечку, и разберем по шагам несколько эффективных способов решения проблемы — от тонкой настройки кэша до альтернативного программирования структуры РИБ в обход штатных механизмов выгрузки.

Выясним причину: почему возникает эта ошибка?

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

1. Аварийный разрыв сессии (/e1cib/logform): Ресурс /e1cib/logform отвечает за передачу данных интерфейса управляемых форм между клиентом и сервером 1С. Когда платформа пытается сгенерировать начальный образ РИБ, на сервере запускаются тяжелые транзакции. Если рабочий процесс rphost падает из-за утечки памяти или критической ошибки базы данных, соединение разрывается, и клиент выдает эту общую сетевую ошибку.
2. Ненайденное поле (_Fld1426RRef): Суффикс RRef указывает на реквизит типа «Ссылка» (например, ссылка на справочник или документ), который был добавлен разработчиком в конфигурацию. Обозначение Т2 говорит о том, что СУБД обращается к временной таблице или к таблице в левом соединении сложного SQL-запроса. Ошибка возникает из-за рассинхронизации: логическая структура метаданных в конфигурации 1С ссылается на этот реквизит, но физически в таблицах СУБД (или во временных таблицах, сформированных сервером 1С) этой колонки не оказывается.

Ниже мы подробно рассмотрим пять практических способов решения данной проблемы, от простых административных мер до профессионального обходного пути.

Способ 1. Альтернативное создание подчиненного узла РИБ (профессиональный обходной путь)

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

Проанализируем этот алгоритм по шагам:

1. Инициализируем узел в центре: Запустите центральную базу данных в режиме «1С:Предприятие». Перейдите в ваш план обмена (например, «По организациям») и создайте там новый элемент — будущий подчиненный узел. Запишите его код (например, УЗ01).
2. Создаем копию базы: Сделайте полную копию центральной информационной базы. Если база клиент-серверная, сделайте резервную копию базы на SQL-сервере или выгрузите её в файл .dt.
3. Разворачиваем копию: Создайте новую пустую информационную базу (для ускорения процесса рекомендуется делать это в файловом режиме) и загрузите туда полученную копию. Теперь эта копия содержит абсолютно те же метаданные и физические таблицы, что и центральная база.
4. Снимаем главный узел и принудительно назначаем подчиненность: Запустите созданную копию базы в режиме «Предприятие». На данный момент она считает себя главной (центральной) базой. Нам необходимо заставить её стать подчиненной по отношению к нашей центральной базе. Для этого откроем внешнюю обработку «Групповая обработка объектов» или создадим простейшую обработку с кодом на встроенном языке 1С и выполним следующий скрипт:

// Программное превращение копии базы в подчиненный узел РИБ
Процедура УстановитьГлавныйУзелНаКлиенте()
    // Находим в плане обмена узел, соответствующий нашей главной базе
    СсылкаНаЦентральныйУзел = ПланыОбмена.ПоОрганизациям.НайтиПоКоду("ЦБ");
    
    Если НЕ СсылкаНаЦентральныйУзел.Пустая() Тогда
        // Устанавливаем связь. База получит статус подчиненной
        ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаЦентральныйУзел);
        Сообщить("Узел успешно переведен в статус подчиненного!");
    Иначе
        Сообщить("Критическая ошибка: Центральный узел с кодом 'ЦБ' не найден!");
    КонецЕсли;
КонецПроцедуры

После выполнения метода ПланыОбмена.УстановитьГлавныйУзел() база автоматически перезапустится и станет полноценным подчиненным узлом.

5. Очищаем лишнюю регистрацию изменений: Поскольку мы скопировали центральную базу целиком, в таблицах регистрации обмена подчиненного узла останутся старые записи. Запустите встроенную обработку «Регистрация изменений для обмена данными» и полностью очистите (отмените) регистрацию изменений для всех объектов.
6. Удаляем ненужные данные: Так как мы настраиваем обмен «По организации», в новую подчиненную базу скопировались данные по всем остальным организациям. С помощью группового удаления данных или написания несложной обработки удалите документы и справочники по тем организациям, информация по которым не должна находиться в этом узле.

Способ 2. Реструктуризация и полное исправление структуры базы данных

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

Рассмотрим порядок действий для исправления структуры таблиц:

1. Выгрузка и загрузка через файл .dt: Это самый мощный инструмент нормализации структуры базы SQL. Выгрузите базу в файл .dt из конфигуратора. Затем создайте на SQL-сервере абсолютно новую пустую базу данных и загрузите файл обратно. При импорте из .dt платформа 1С генерирует физические таблицы СУБД с нуля строго по эталонной схеме метаданных, что автоматически устраняет все ошибки вида «поле не найдено».
2. Тестирование и исправление в конфигураторе: Запустите конфигуратор, перейдите в меню «Администрирование» — «Тестирование и исправление». Обязательно установите флаги напротив опций «Реиндексация таблиц информационной базы» и «Реструктуризация таблиц информационной базы». Процесс реструктуризации принудительно пересоздаст проблемные таблицы и добавит отсутствующие колонки, включая физическое поле _Fld1426RRef.

Способ 3. Очистка кэша на стороне сервера приложений 1С

Иногда физически колонка в базе данных SQL присутствует, но сервер 1С обращается к старой версии схемы из своего внутреннего кэша. Очистка локального кэша пользователя на клиентском компьютере здесь не поможет — требуется очистить кэш на самом сервере приложений.

Выполним процедуру очистки серверного кэша:

1. Остановите службу сервера 1С:Предприятия (через оснастку services.msc найдите службу «Агент сервера 1С:Предприятия» и нажмите «Остановить»).
2. Перейдите в каталог хранения служебных файлов сервера. По умолчанию в ОС Windows это путь: C:\Program Files\1cv8\srvinfo\reg_1541.
3. Внутри каталога вашего кластера удалите все папки с длинными буквенно-цифровыми именами (UID), которые содержат кэш метаданных информационных баз, а также очистите содержимое папки snccntry.
4. Запустите службу сервера заново. При первом обращении пользователей сервер 1С заново сформирует актуальный кэш структуры СУБД.

Способ 4. Временное файловое создание узла РИБ

В платформе 1С:Предприятие (особенно в линейках релизов 8.3.13.хххх и некоторых версиях 8.3.14.хххх) существовал зарегистрированный баг, при котором создание нового образа подчиненного узла в серверном режиме приводило к критической ошибке СУБД.

В качестве эффективного обходного маневра мы можем создать начальный образ в файловом режиме:

1. В окне создания начального образа укажите тип расположения подчиненной базы: «На данном компьютере или на компьютере в локальной сети» (файловый вариант), даже если сама центральная база работает на SQL.
2. Укажите пустой локальный каталог для создания файловой базы.
3. Запустите процесс создания образа. В файловом режиме СУБД используется другой движок генерации таблиц, что позволяет успешно миновать ограничения SQL-запросов и создать базу без ошибок.
4. После того как файловая подчиненная база будет успешно создана, вы сможете легко перенести её на SQL-сервер (через выгрузку/загрузку .dt), если для работы подчиненного узла требуется именно клиент-серверный режим.

Способ 5. Отключение расширений конфигурации и проверка планов обмена

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

Проанализируем влияние расширений:

• Попробуйте временно отключить все активные расширения конфигурации (снимите флаг «Активно» в меню «Конфигурация» — «Расширения конфигурации» в режиме Конфигуратора).
• Попробуйте запустить генерацию начального образа без них. Если генерация прошла успешно, значит, добавленные в расширении реквизиты некорректно обрабатываются планом обмена.
• Убедитесь, что в свойствах вашего плана обмена (например, ОбменПоОрганизации) установлена поддержка расширений, либо реквизиты расширения не задействованы в составе регистрируемых к обмену объектов без явной необходимости.

Используя предложенные методики, вы сможете быстро локализовать источник проблемы и успешно запустить обмен данными между вашими филиалами и центральным офисом!