В практике администрирования файловых баз данных 1С:Предприятие 8.3 нередко встречаются ситуации, когда после копирования базы на другой компьютер, обновления платформы или восстановления из архива пользователь сталкивается с критической ошибкой SDBL. Одной из самых загадочных и неприятных является ошибка, связанная с разделением данных.
Рассмотрим подробно ситуацию, когда при запуске в пользовательском режиме (или даже при попытке входа в Конфигуратор) платформа выдает сообщение:
"Невосстановимая ошибка. Ошибка при выполнении запроса POST к ресурсу /e1cib/modules/call: по причине: Ошибка SDBL: Таблица или поле DataSeparationUse... не содержится в разделе FROM"
Разберем причины возникновения этой неисправности и проанализируем эффективные методы ее устранения, от простых проверок до глубокой реструктуризации базы данных.
Прежде чем приступать к лечению, давайте поймем механизм возникновения сбоя. Поле, упоминаемое в ошибке (обычно это DataSeparationUse с цифровым суффиксом, например DataSeparationUse12061), относится к механизму Разделения данных (Data Separation). Этот механизм используется в облачных технологиях (1cfresh, SaaS), чтобы в одной физической базе данных хранить данные множества независимых абонентов. Подобные проблемы часто возникают, когда выполняется перенос базы 1С из доработанной конфигурации в "облаке" в типовую локальную версию, и следы облачной инфраструктуры остаются в метаданных.
В локальной файловой версии "Бухгалтерии" или "ЗУП" разделение данных обычно отключено. Однако, если платформа "думает", что разделение включено, она автоматически добавляет к каждому запросу условие WHERE (ГДЕ), фильтрующее данные по текущему разделителю.
Ошибка "не содержится в разделе FROM" означает рассинхронизацию:
DataSeparationUse.Чаще всего это происходит из-за повреждения кэша метаданных базы (таблица DBSCHEMA) после динамических обновлений или некорректного завершения работы.
В исходной теме упоминалось, что "Тестирование и исправление" в Конфигураторе не помогло. Это логично, так как Конфигуратор работает на уровне логической целостности, а ошибка лежит глубже — на уровне физических страниц файла базы данных.
Начнем с использования специализированной утилиты, входящей в поставку платформы.
chdbfl.exe. Он находится в папке bin установленной версии платформы (например, C:\Program Files\1cv8\8.3.20.xxxx\bin\).1Cv8.1CD (обязательно сделайте резервную копию перед этим!).Эта утилита проверяет заголовки страниц и таблиц. Часто ошибка SDBL возникает из-за "битой" ссылки в таблице конфигурации, и chdbfl.exe способна это исправить. Если ошибок не найдено или исправление не помогло, переходим к следующему этапу.
Иногда проблема кроется не в самом файле данных, а во временных файлах, которые были скопированы вместе с базой. Если вы копируете папку целиком, убедитесь, что вы не перенесли "мусор", который заставляет платформу думать, что сеанс с разделением данных все еще активен.
Выполним очистку каталога базы. Чтобы упростить этот процесс и не удалить лишнего, можно использовать готовый Bat файл для очистки кеша 1С (серверного и клиентского), который сохраняет журналы регистрации и настройки.
Если делать это вручную:
1Cv8.1CD.1Cv8.pfl (файл блокировок)lock.txt1Cv8Log (журнал регистрации — если он не критичен, или переместите его)cmi, fRS.xml и прочие служебные файлы.Попробуйте запустить базу. Платформа создаст необходимые служебные файлы заново.
Если база открывается в Конфигураторе, но не работает в Предприятии, мы можем попытаться заставить платформу пересоздать структуру таблиц, отвечающих за разделение данных. Перед внесением изменений полезно провести анализ конфигураций, расширений, отчетов и обработок на наличие ошибок, чтобы убедиться, что проблема не вызвана некорректным кодом в подключенных расширениях.
В теме обсуждалась попытка изменить свойства "Разделение данных" в общих реквизитах, что приводило к ошибкам параметров сеанса. Пойдем другим путем — методом переименования.
Выполним следующие действия:
ОбластьДанныхОсновныеДанныеОбластьДанныхВспомогательныеДанныеОбластьДанныхОсновныеДанные.ОбластьДанныхОсновныеДанные_RENAME.Что происходит в этот момент?
Платформа видит, что объект переименован. На уровне СУБД (даже файловой) она должна изменить структуру хранения. Это заставляет движок переписать метаданные таблицы, часто устраняя рассинхронизацию SDBL.
ОбластьДанныхОсновныеДанные.Если при обновлении возникает ошибка, попробуйте сделать то же самое, но выбрав в меню Конфигурация —> Поддержка —> Настройка поддержки и включив возможность изменения для корня конфигурации (если база была на замке).
Если штатные средства бессильны, опытные специалисты прибегают к использованию инструмента Tool_1CD (неофициальный просмотрщик и редактор файлов .1CD). Этот метод требует осторожности и обязательной резервной копии.
Суть метода заключается в очистке таблицы CONFIG от записей, содержащих скомпилированную схему базы данных (DBSCHEMA). Платформа хранит кэш структуры базы внутри самого файла базы данных. Если этот кэш поврежден (например, после динамического обновления), возникает ошибка SDBL.
Алгоритм действий (теоретический, для ознакомления):
Tool_1CD.CONFIG.DBSCHEMA, если она доступна для редактирования) заставляет Конфигуратор при следующем запуске считать, что конфигурация БД отличается от конфигурации поставщика/разработчика, и запустить полную реструктуризацию.Примечание: Данный метод рекомендуется только опытным системным администраторам, так как риск повредить базу окончательно весьма велик.
Если база данных повреждена настолько, что восстановить структуру не удается, или на это уходит слишком много времени, наиболее надежным решением является перенос данных в чистую базу. Это именно то, что в итоге сделал автор вопроса.
Этот метод гарантирует отсутствие скрытых ошибок в будущем, так как вы начинаете работу с технически исправного файла 1Cv8.1CD.
Пошаговый план переноса:
cf из поставки).Данная модификация типовой обработки позволяет производить обмен данными даже между не полностью идентичными конфигурациями и выгружать справочники, документы и регистры в файл XML без жесткого контроля ссылочной целостности на этапе выгрузки.
Ошибка DataSeparationUse... not contained in FROM — классический пример рассогласования метаданных и физической структуры в файловом варианте работы 1С. Основной причиной чаще всего являются динамические обновления.
Рекомендация на будущее:
Чтобы избежать подобных проблем, старайтесь не злоупотреблять динамическим обновлением конфигурации базы данных, особенно если в структуре меняются важные общие реквизиты или параметры сеанса. Периодически выполняйте выгрузку в .dt файл и загрузку обратно, так как эта операция полностью пересоздает файлы таблиц базы данных, очищая их от "мусора" и внутренней фрагментации.