← На главную

При переходе на новые версии платформы 1С:Предприятие 8.3 (начиная с 8.3.21, 8.3.22 и выше) и повышении режима совместимости конфигурации многие технические специалисты сталкиваются с критической ошибкой SDBL. Текст ошибки обычно выглядит так: Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm: по причине: Ошибка SDBL: Таблица или поле LastUpdate не содержится в разделе FROM. Также возможен вариант с полем NumberPrefix.

В этой статье мы подробно разберем причины возникновения данной ситуации и рассмотрим пошаговые методы её решения, основываясь на практическом опыте разработчиков.

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

Для начала проанализируем ситуацию с технической точки зрения. Появление этой ошибки связано с тем, что механизм SDBL (System Data Business Logic) — промежуточный слой между кодом «1С» и SQL-запросами — ожидает увидеть в структуре базы данных определенные системные поля, которые платформа добавляет автоматически при повышении режима совместимости.

• Поле LastUpdate (Дата актуальности) — это новое системное поле, которое платформа начала добавлять в таблицы ПланыОбмена для оптимизации механизмов регистрации изменений.
• Поле NumberPrefix — системное поле, добавляемое в таблицы Нумераторы или Документы для улучшения логики хранения префиксов в распределенных базах.

Проблема возникает именно с расширениями конфигурации. Когда мы повышаем режим совместимости основной базы, платформа должна выполнить реструктуризацию всех таблиц. Однако из-за специфического бага платформы таблицы, созданные или заимствованные в расширения объекты (имеющие в SQL префикс _Ext...), иногда пропускаются механизмом реструктуризации. В итоге код платформы уже «хочет» прочитать данные из поля LastUpdate, а физически в таблице расширения этого столбца ещё нет. Для исследования состава таблиц и полей на уровне СУБД можно использовать обработку для анализа структуры хранения базы данных.

Способ 1: Полное пересоздание объектов расширения через выгрузку данных

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

Разберем по шагам:

1. Воспользуемся обработкой ВыгрузкаЗагрузкаДанныхXML83.epf. Нам необходимо выгрузить все данные расширения, которые связаны с проблемным объектом (например, узлы планов обмена). Важно: делайте это в копии базы, где ошибка ещё не успела «сломать» процесс выгрузки, или используйте версию до обновления режима совместимости.
2. В конфигураторе полностью удалите расширение из информационной базы. Это действие должно пройти без ошибок SDBL, так как таблицы расширения будут просто удалены.
3. Запустите базу в пользовательском режиме (без расширения), чтобы платформа зафиксировала отсутствие метаданных.
4. Снова добавьте расширение в базу. Установите в нем необходимый режим совместимости (соответствующий основной конфигурации).
5. Загрузите ранее выгруженные данные с помощью той же обработки ВыгрузкаЗагрузкаДанныхXML83.epf.

Если объектов в расширении много, можно попробовать удалить только проблемный объект (например, только ПланОбмена) внутри расширения, применить изменения, а затем создать его заново с тем же именем.

Способ 2: Перенос объекта в основную конфигурацию

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

Алгоритм действий:

• Перенесите ПланОбмена или Нумератор из расширения в основную конфигурацию (используя сравнение/объединение или создав объект вручную).
• Удалите заимствованный или созданный объект из расширения.
• Примените изменения.

В этом случае поле LastUpdate (Дата актуальности) будет создано платформой корректно, и ошибка исчезнет.

Способ 3: Правильная последовательность обновления (для предотвращения ошибки)

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

1. Обновите версию платформы «1С:Предприятие» на всех серверах и клиентах.
2. Повысьте режим совместимости только основной конфигурации. Примените изменения в монопольном режиме.
3. Запустите базу, убедитесь в стабильности работы.
4. И только после этого приводите режим совместимости расширения в соответствие с основной конфигурацией.

Синхронное изменение режимов совместимости и в базе, и в расширении часто приводит к рассинхронизации метаданных SDBL и физической структуры SQL.

Особенности для объектов типа «Нумератор» (поле NumberPrefix)

Рассмотрим пример, когда ошибка возникает из-за нумератора. Если в расширение был заимствован нумератор и в нем изменена периодичность (например, с «Непериодический» на «В пределах года»), это может спровоцировать ошибку NumberPrefix не содержится в разделе FROM.

Решение в данном случае:

• Временно верните настройки нумератора в расширении к исходным (как в основной конфигурации).
• Обновите основную конфигурацию и платформу.
• После успешного обновления снова установите нужную периодичность в расширении.

Дополнительные технические приемы

Если вышеуказанные способы не помогают, рассмотрим более глубокие методы очистки кэша метаданных на стороне сервера:

1. Очистка серверного кэша: Остановите службу агента «1С:Предприятия», удалите содержимое папки srvinfo (за исключением файлов лицензий и логов регистрации) и запустите службу снова.
2. Тестирование и исправление: Запустите ТиИ с флагом Реструктуризация таблиц информационной базы. Внимание: при выполнении этой операции расширения должны быть подключены, а база находиться в монопольном режиме.
3. Принудительное переименование: Попробуйте переименовать объект в расширении (например, МойПланОбмена -> МойПланОбмена_Временный), применить изменения, а затем вернуть имя обратно. Это иногда инициирует обновление структуры таблиц _Ext... в SQL.

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