При обновлении нетиповых конфигураций, резком повышении режима совместимости платформы или попытке реструктуризации базы данных разработчики 1С часто сталкиваются с критической ошибкой. Сообщение выглядит так: В процессе обновления информационной базы произошла критическая ошибка по причине: Ошибка SDBL: Таблица или поле Fld18715 не содержится в разделе FROM (pos=401). Разберем эту проблему подробно и выясним причины ее возникновения, а также рассмотрим комплексные методы восстановления работоспособности системы.
Проанализируем ситуацию на базовом уровне. Ошибка SDBL (Standard Database Language — внутренний язык запросов 1С) сигнализирует о том, что произошла рассинхронизация метаданных конфигурации 1С и физической структуры таблиц в используемой СУБД (Microsoft SQL Server или PostgreSQL). Платформа "ожидает" увидеть определенную колонку, к которой обращается в запросе, но физически в таблице базы данных её нет.
Чаще всего эта ситуация возникает в следующих случаях:
Рассмотрим подробнее каждый из возможных способов решения данной задачи. Начнем с самых безопасных и перейдем к методам прямого вмешательства в базу данных.
Разберем по шагам правильную процедуру перехода между старыми и новыми релизами платформы. В версиях платформы 8.3.3, 8.3.4 и 8.3.8 кардинально менялись форматы хранения внутренних данных. Если вы попытаетесь перепрыгнуть эти релизы, структура базы может быть безвозвратно повреждена.
Если у вас есть резервная копия до возникновения ошибки, выполним следующие действия:
Часто проблема кроется в зависших сеансовых данных кластера серверов 1С. Рассмотрим, как правильно очистить кэши на стороне сервера, так как обычная очистка пользовательского кэша в этой ситуации не поможет.
Выполним следующие шаги:
c:\Program Files\1cv8\srvinfo\reg_1541\.snccntxf9e2add1-c791-4bb9-8234-5f22914bd922).snccntx.dat.Если откатиться на копию невозможно, так как в базе уже есть важные данные за последние дни, проанализируем структуру базы на уровне СУБД. Суть метода заключается в том, чтобы вручную "подсунуть" платформе недостающее поле, чтобы она смогла завершить реструктуризацию. Для быстрого определения физических имен таблиц и полей в СУБД можно использовать обработку для просмотра структуры хранения базы данных.
Разберем по шагам этот сложный, но действенный метод:
_Document154).Fld18715).Для добавления колонки можно использовать простой SQL-запрос:
ALTER TABLE _Document154
ADD _Fld18715 NUMERIC(15, 2) NULL;
Тип данных можно задать универсальным или подсмотреть у соседних реквизитов. После добавления колонки снова запустим реструктуризацию в Конфигураторе 1С. Платформа "увидит" поле, успешно завершит процесс и сама приведет структуру таблиц в порядок (переопределит тип или удалит временную колонку).
Даже если в базе визуально нет подключенных расширений, на уровне SQL могут остаться следы от ранее удаленных модулей. Посмотрим на структуру базы в СУБД. Нас интересуют таблицы с суффиксом X1.
Таблицы расширений имеют вид _Document123X1. При реструктуризации платформа пытается обратиться к этим таблицам, но основные поля в них могут отсутствовать, что и вызывает ошибку SDBL. Для решения этой проблемы необходимо либо очистить такие таблицы напрямую в СУБД, либо скопировать из них данные в основные таблицы (если они нужны), а затем удалить зависшие таблицы расширений.
Рассмотрим еще два неочевидных метода, которые помогают обойти платформенные баги.
Отключение разделения данных: Иногда проблема кроется в общих реквизитах, у которых включено свойство РазделениеДанных. Выясним причину: перед реструктуризацией временно отключим использование разделения данных (установим свойство в значение "Не использовать"), обновим конфигурацию базы данных, а затем вернем настройки обратно.
Откат на стабильный релиз платформы: Если ошибка проявилась на свежем релизе (например, 8.3.21), запустим базу в конфигураторе под управлением более старой и стабильной платформы (например, 8.3.17). Часто механизмы реструктуризации в старых версиях отрабатывают без критических сбоев. После успешной реструктуризации можно снова вернуться на актуальную версию.
Также, если вы работаете с копией базы, убедитесь в отсутствии блокировок копий. Для этого создайте пустой текстовый файл DoNotCopy.txt в корневом каталоге кластера сервера 1С. Это отключит внутренние механизмы 1С по обработке копий ИБ, которые могут конфликтовать с изменением структуры.
Если ни один из методов реструктуризации не помог, а восстановить данные необходимо любой ценой (например, пользователи завели большое количество сложных документов), разберем радикальный способ спасения информации.
Суть метода: мы разворачиваем работоспособную конфигурацию из бэкапа (до сбоя) и переносим в нее новые данные из сломанной базы напрямую через SQL-запросы.
Выполним процедуру восстановления по шагам:
_IDRRef, чтобы не потерять связи между документами.УстановитьСсылкуНового().Пример концептуального кода обработки для загрузки данных в новую базу:
// Создаем новый документ
НовыйДокумент = Документы.ЗаказПокупателя.СоздатьДокумент();
// Получаем УИД из выгруженного SQL файла (строковое представление)
УИД_Строка = СтрокаИзФайла.УИД;
НовыйУИД = Новый УникальныйИдентификатор(УИД_Строка);
СсылкаНаНовыйОбъект = Документы.ЗаказПокупателя.ПолучитьСсылку(НовыйУИД);
// Привязываем старый УИД к новому документу
НовыйДокумент.УстановитьСсылкуНового(СсылкаНаНовыйОбъект);
// Заполняем остальные реквизиты
НовыйДокумент.Дата = СтрокаИзФайла.Дата;
НовыйДокумент.Контрагент = НайтиКонтрагентаПоУИД(СтрокаИзФайла.КонтрагентУИД);
// Записываем документ
НовыйДокумент.Записать(РежимЗаписиДокумента.Проведение);
Этот процесс трудоемок, однако он гарантирует сохранение критически важных данных (например, сложных задач, событий CRM и цепочек документов), которые восстановить вручную практически невозможно. После переноса данных обязательно пересчитайте итоги и запустите утилиту тестирования и исправления базы данных.