В процессе обновления измененных конфигураций «1С:Предприятия», работающих на клиент-серверной версии под управлением СУБД MS SQL, разработчики иногда сталкиваются со сложной системной ошибкой. Платформа прерывает реструктуризацию и выдает сообщение вида: «Ошибка SDBL: Таблица AccumRgOpt не имеет нового поколения и не может быть модифицирована». В некоторых случаях попытка исправить базу в файловом режиме через утилиту тестирования и исправления (ТиИ) приводит к другой ошибке: «Ошибка SDBL: Ожидается CREATE, DROP, RENAME, REPLACE или SELECT».
Давайте подробно проанализируем причины возникновения этой проблемы, разберемся, как устроена технология версионирования таблиц в платформе 1С, и рассмотрим практические шаги по ее устранению как на уровне СУБД MS SQL, так и встроенными средствами платформы.
Аббревиатура SDBL (Simple Data Base Layer) обозначает собственный промежуточный слой платформы «1С:Предприятие», который служит транслятором между внутренними запросами системы и СУБД (MS SQL, PostgreSQL, IBM DB2 or Oracle Database). Когда мы вносим изменения в метаданные и запускаем обновление конфигурации базы данных, запускается механизм реструктуризации таблиц. Он работает по принципу версионирования («поколений»):
AccumRgOpt или таблицы самого регистра) платформа создает копию — таблицу «нового поколения» со временным именем.Если на этапе переноса данных или обновления индексов происходит аварийное завершение процесса (например, из-за нехватки свободного места на диске, переполнения журнала транзакций SQL, сбоя службы rphost или отключения электроэнергии), транзакция прерывается. В служебной таблице метаданных 1С фиксируется признак того, что таблица переведена на новое поколение, но физически в СУБД этот процесс остался незавершенным. В результате база данных зависает в промежуточном состоянии, и при любой последующей попытке обновиться или записать новый элемент конфигуратор возвращает ошибку SDBL.
Рассмотрим пошагово рабочие методы устранения этой проблемы.
Как показывает практика и опыт многих разработчиков, появление подобных ошибок версионирования таблиц (особенно на старых базах данных вроде «Управление торговлей 10.3» или «Управление производственным предприятием 1.3») часто связано с внутренними багами конкретных релизов платформы 1С. В определенных версиях движка механизмы реструктуризации некорректно обрабатывали таблицы настроек хранения итогов.
Проанализируем ситуацию: если ваша конфигурация давно не обновлялась и вы пытаетесь работать с ней на устаревшей или, наоборот, слишком новой платформе, попробуйте запустить базу под управлением стабильного технологического релиза. В частности, для решения проблем со сбоями реструктуризации старых конфигураций отлично подходит стабильный релиз платформы 8.3.10.2772. Переход на эту версию позволяет платформе корректно распознать структуру устаревших таблиц и успешно завершить процесс реструктуризации без выдачи ошибок SDBL.
Если база данных оказалась заблокированной на этапе обновления и не позволяет войти в Конфигуратор для выполнения штатного тестирования и исправления, мы можем принудительно сбросить флаг незавершенного обновления через СУБД.
Перед началом любых манипуляций на уровне SQL обязательно создайте резервную копию базы данных (бэкап)!
Выполните следующие шаги:
UPDATE SchemaStorage
SET Status = 100;
Значение Status = 100 сообщает платформе «1С», что процесс обновления конфигурации успешно завершен. После выполнения этого запроса вы сможете беспрепятственно запустить Конфигуратор, зайти в базу данных и выполнить штатные процедуры обслуживания.
Если ошибка SDBL указывает на конкретную таблицу, такую как AccumRgOpt (таблица настроек хранения итогов регистров накопления), и при этом стандартное ТиИ падает с синтаксической ошибкой, мы можем прибегнуть к радикальному, но эффективному методу — удалению таблицы на уровне СУБД с последующим автоматическим пересозданием.
Выясним физическое имя таблицы в СУБД. Название AccumRgOpt является логическим именем в терминах 1С. В SQL-базе эта таблица обычно называется _AccumRgOpt (иногда с дополнительными индексами). Нам нужно определить точное имя.
Для определения точного имени таблицы напишем небольшую обработку в 1С и выполним следующий код:
СтруктураХранения = ПолучитьСтруктуруХраненияБазыДанных();
Для Каждого СтрокаТЧ Из СтруктураХранения Цикл
Если Найти(СтрокаТЧ.ИмяТаблицыХранения, "AccumRgOpt") > 0 Тогда
Сообщить("Имя таблицы в СУБД: " + СтрокаТЧ.ИмяТаблицыБД);
КонецЕсли;
КонецЦикла;
После того как точное имя таблицы определено (допустим, это _AccumRgOpt), выполним ее удаление в MS SQL Server Management Studio:
DROP TABLE _AccumRgOpt;
После удаления таблицы запустите Конфигуратор. Платформа обнаружит отсутствие таблицы настроек хранения итогов и автоматически пересоздаст ее пустой со значениями по умолчанию. Затем обязательно зайдите в режим предприятия и перейдите в меню управления итогами, чтобы восстановить настройки хранения для регистров накопления.
Если ошибка поколения возникает при обращении к какому-то конкретному регистру накопления или сведений, мы можем заставить платформу принудительно пересоздать структуру этого объекта и все связанные с ним таблицы «с нуля».
Разберем этот процесс по шагам:
ВременныйРеквизитДляРеструктуризации и типом данных Булево.Иногда физические таблицы в СУБД находятся в порядке, но сам сервер приложений «1С:Предприятия» кэширует устаревшее соответствие имен таблиц и их поколений. Локальная очистка кэша на клиентском компьютере в этом случае не дает результата.
Для исправления ситуации выполним полную очистку кэша на стороне сервера:
services.msc).C:\Program Files\1cv8\srvinfo).reg_1541) и удалите внутри нее все подкаталоги с именами формата UUID (например, 14690623-cb4b-4a57-8a18-d71689b14b8a), которые содержат сеансовые кэши и настройки транзакций. Внимание: не удаляйте файлы лицензий и файлы самих файловых баз данных, если они случайно там находятся!Применяя данные подходы последовательно, мы гарантированно избавимся от ошибок SDBL и успешно обновим рабочую базу данных.