Extensionsrestructngs что за таблица
Ошибка SDBL: Таблица или поле configversion не содержится в разделе FROM
При выполнении каких-либо действий в системе 1С (открытии документа, установки библиотеки, обновлении БД и других смежных операций) пользователь может столкнуться с сообщением « Ошибка SDBL: Таблица или поле configversion не содержится в разделе FROM ». Обычно это связано с техническим сбоем в работе 1С, и лечиться рядом способов, описанных нами ниже. В данном материале мы разберём, в чём суть данной дисфункции, и как её исправить.
Почему возникает ошибка
Рассматривая нами ошибка SDBL является представительницей целого пула схожих ошибок с текстом « Таблица или поле не содержится в разделе FROM ». Такие ошибки обычно связаны с повреждением базы данных из-за различных причин, самой распространённой из которых является технический сбой в работе системы 1С.
Среди других причин ошибки SDBL также выделяют:
Ошибка возникает при попытке обновления базы данных, добавления документа в базу данных, при тестировании базы данных на логическую целостность и других схожих случаях. При этом перезагрузка системы обычно никак не решает возникшую проблему.
Давайте рассмотрим, как исправить ошибку SDBL: Таблица или поле в вашей системе 1С.
Убедитесь в наличии достаточных прав для запуска системы
Первым делом убедитесь, что вы запускаете вашу систему с правами администратора. Недостаточный уровень прав может приводить к появлению различных проблем при работе с 1С.
Обновите вашу конфигурацию (платформу) 1С
Также проверьте, пользуетесь ли вы самой свежей версией платформы (конфигурации) 1С. При необходимости обновите вашу систему до самой свежей версии продукта. Это может помочь устранить ошибку SDBL с полем configversion в 1С.
Используйте инструмент «Тестирование и исправление».
Данный инструмент запускается переходом в конфигуратор, где в разделе «Администрирование» нужно выбрать опцию «Тестирование и исправление». Дождитесь окончания процедуры, после чего проблема может быть решена.
Исправьте ошибки в ваших базах данных
Выгрузите и загрузите файл Dt
Для загрузки выгруженной ранее базы в систему вновь запустите «Конфигуратор», перейдите на вкладку «Администрирование», и в ней активируйте опцию «Загрузить информационную базу». Это может помочь избавиться от ошибки «SDBL: Таблица или поле configversion»
Перезагрузите сервер 1С
Для устранения дисфункции рекомендуем перезагрузить сервер 1С. Перезагрузка указанного сервера обычно выполняется автоматически на протяжении 3-5 минут при условии отсутствия у сервера подключенных пользователей.
Очистите кэш сервера 1С
В некоторых случаях исправить ошибку SDBL можно с помощью очистки кэша сервера 1С. Обычно кэш расположен по адресу:
Туда нужно перейти и удалить папки с генерированными именами. Учтите, что кроме кэша в данной папке могут находиться журналы регистрации, а также индекс полнотекстового поиска 1С.
Очистите таблицы в менеджере SQL
Также можно попробовать выполнить очистку таблиц таблицы _ConfigChngR и _ConfigChngR_ExtProps с помощью команды delete.
Заключение
В нашем материале мы разобрали причины ошибки «SDBL: Таблица или поле configversion не содержится в разделе FROM» и способы её устранения. Среди всех перечисленных альтернатив хорошую эффективность показал способ с выгрузкой файлов базы данных (файл с расширением Dt), с последующей их повторной загрузкой. Обычно после этого ошибка бывает устранена, и вы сможете пользоваться нормальным функционалом системы 1С.
Ошибка SDBL в 1С
Возникновение ошибки SDBL
Ошибка SDBL возникает, когда происходит обновление конфигурации 1С:Предприятие или сохранение перемен. Также сообщение об ошибке может возникать при работе с обменами данных:
Рис. Сообщения 1С об ошибке SDBL
Также к данным сообщениям часто есть одна или несколько приписок:
Обратите внимание: есть вероятность, что при ошибке будут другие сообщения, не указанные выше!
Устранение ошибки SDBL в 1С
Устранить ошибку SDBL можно одним из способов, которые описаны ниже.
1. Сделать перезагрузку на сервере с приложениями для 1С 8.3. Далее может помочь, если включить и выключить все сервисы SQL и агентами SQL. Для этого потребуется зайти на сервер, выбрать «Агент сервера 1С» и при помощи контекстного меню приостановить работу. По аналогии сделаем с «Агентом SQL» и «SQL Server» для сервера SQL. Затем следует снова подключить их, но в обратной последовательности.
2. Выгрузить базу с данными в некоторый файл, который будет иметь расширение DT, а затем выгрузить её назад – в ту же базу с информацией. Аналогично будет исполняться для режима конфигуратора при помощи вкладки меню «Администрирование» – посредством использования команд «Загрузить информационную базу…» и «Выгрузить информационную базу…».
3. Можно попробовать очистить КЭШ внутри сервера и внутри компьютера пользователя в месте, где была обнаружена ошибка. Для этого потребуется закрыть 1С, далее совершить поиск по папкам, которые будут иметь имя вида «bd5c8ea4-b65f-4c23-a9c8-2dccfb0b15fa» внутри папки с названием «Application Data», после их нахождения производим удаления данных папок.
4. Также можно обновить платформу на более современную версию (с главного портала – ИТС). Для выполнения данного действия скачиваем с ИТС новую платформу 1С 8.3 и устанавливаем ее на компьютерах клиентов и на сервере.
5. Рассмотрим еще один вариант – использование механизма «Тестирование и исправление информационных баз», который находится внутри конфигуратора. В необходимой базе переходим по пути: «Администрирование → Тестирование и исправление информационных баз», а далее запускаем процесс.
6. Совершим загрузку внутри копии, которая является резервной, если она была создана в недавнем времени. Замечание: обязательно часто делать резервные копии до любого важного действия с ИБ. Копии делаются посредством SQL MS или конфигуратора, при этом происходит выгрузка файла в формат dt.
Если ни один из вышеперечисленных способов не устранил ошибку SDBL, следует произвести очистку таблиц _ConfigChngR_ExtProps и _ConfigChngR. Однако для этого потребуется знания принципов работы MSSQL.
Ошибка SDBL в 1С
Обычно ошибка SDBL происходит при сохранении и обновлении конфигураций в момент реструктуризации базы данных, а также во время работы обменов данными.
Окно с данной ошибкой 1С имеет дополнительное содержание. Типичные сообщения:
Исправление ошибки SDBL
Большая часть способов исправления связана с восстановлением нормальной работы Информационной Базы. Но иногда описанными способами решить проблему не получается, поэтому помните о самом лучшем, универсальном способе — регулярном резервном копировании.
Перезагрузка сервера 1С и SQL-сервера
Самый простой способ, при условии, что на текущий момент в базе никто не работает.
Зайдите на сервер и выключите следующие службы:
А затем запустите их обратно.
Очистка кэша на сервере и клиента, где проявилась ошибка
В некоторых случаях исправить ошибку SDBL можно с помощью очистки кэша сервера 1С.
Как правило кэш расположен по адресу:
Перейдите в данный каталог и удалить все папки с генерированными именами вида « dg7c8re4-b89r…». При удалении будьте внимательны — в этой директории может присутствовать индекс полнотекстового поиска 1С, а также журналы регистрации, их удалять не нужно.
Перезаливка базы из DT-файла
Иногда помогает, казалось бы, парадоксальный способ — выгрузка базы данных в файл формата DT, а затем загрузка его обратно.
Войдите в режим «Конфигуратор», выберите пункт меню «Администрирование» > «Выгрузить информационную базу» и выберите каталог для сохранения файла.
Затем через аналогично через меню «Администрирование» > «Загрузить информационную базу» загрузите его обратно.
Тестирование и исправление Информационной базы
Для тестирование и исправление Информационной базы: войдите в «Конфигуратор», выберите пункт меню «Администрирование» > «Тестирование и исправление».
В случаях, когда невозможно запустить конфигуратор, воспользуйтесь утилитой chdbfl.exe. Это упрощенная программа-аналог тестирования базы, функции, которая запускается в режиме конфигуратора. Расположена она в папке «bin» установленной технологической платформы, например, C:\Program Files (x86)\1cv8\8.3…\bin\chdbfl.exe.
Пользоваться ей просто — указываете путь к файлу базы данных и ставите опцию, нужно ли сразу исправлять обнаруженные ошибки. Если нет — утилита только продиагностирует ИБ.
Обновление платформы до новой версии
В данном случае всё достаточно просто. Скачивает с сайта поддержки 1С дистрибутив свежей версии платформы, распаковываем и запускаем инсталятор setup.exe.
Очистка таблиц базы данных
В крайнем случае можно попробовать удалить таблицы БД, связанные с ошибкой — «dbo._ConfigChngR» и «dbo._ConfigChngR_ExtProps».
Помните, прямые SQL-запросы лучше доверить профессионалу, умеющему работать с SQL.
12 статей про обновление 1С
Типовую программу 1С легко обновить самостоятельно через конфигуратор или интернет. Ещё один способ — использовать cfu-файл. Если пропущено много релизов, вам сэкономят время промежуточные конфигурации.
После обновления не забывайте запустить особые процедуры.
Бывает выгоднее отдать обновление нетиповой 1С на аутсорсинг.
Что нового для вашей 1С?
Рассылка осуществляется в день выхода обновления. Никакой рекламы, только полезная информация. Посмотрите пример →
Ошибка SDBL при обновлении БП 3.0.64.54 => 3.0.65.80 на платформе 8.3.12.1595
Для начала, сразу скажу, что ТИИ базы со всеми галками до обновления сделано, ошибок не выдает.
Конфа БП 3.0.64.54 полностью типовая.
cfu встает без проблем, конфа сохраняется, изменения применяются по F7 успешно.
Потом при обновлении в режиме предприятия падает вот так:
Код процедуры такой:
Эту ошибку можно обойти в отладчике, заменив значение ИмяПланаОбмена = «Полный» на «АвтономнаяРабота» в начале процедуры.
Но потом после того как обновление установится, при попытке сделать ТИИ с галкой «проверка логической целостности» сразу выдается ошибка в виде предупреждения и ТИИ останавливается:
Т.е. фактически на выходе получаем битую базу.
(1) Что делать чтобы обновилось без этой ошибки?
Всё делал на тестовой базе.
Рабочую, естественно, оставил пока на релизе 3.0.64.54.
Но рано или поздно придётся обновлять, а тут такая Ж.
Может быть кто-то уже столкнулся с тем же самым и смог победить.
(3) Я понимаю, что это баг платформы, а не конфы.
Из более свежих только 2 версии 8.3.12.1616 и 8.3.12.1685.
В описании исправленных багов нечто отдаленно похожее нашёл, но не совсем оно:
Файловая без ошибок обновилась на 3.0.65.80.
Правда пустая.
Та же самая ошибка на последней платформе 8.3.13.1513.
(11) Как надо настроить тех.журнал, чтобы попытаться самостоятельно отловить ошибку?
(13) Это я первым делом проверил.
В плане обмена «Полный» только один предопределенный элемент без кода, наименования, т.е. который не использовался никогда.
По остальным планам обмена на всякий случай тоже посмотрел.
У всех остальных, кроме 3-х (ниже), точно такая же картина с одним предопределенным элементом.
(30) Попробовал.
Если сразу после завершения обновления в конфигураторе запустить ТИИ (т.е. даже без запуска предприятия), то вываливается с сообщением, описанным в (0)
Таблица была «dbo._AccRgAT2486», SQL ругался на неуникальность конкретного индекса. В Management Studio я временно разрешил этому конкретного индекса пропускать повторяющиеся значения,а после выполнения всех процедур обратно запретил.
Но что за таблица «dbo._tmpRCT»?
(35) При ТИИ создается такая таблица в скулевской базе:
При ТИИ базы до обновления в таблице _tmpRCT это значение 0x0000001B так же есть, но количество строк в таблице 1268 (больше).
Т.е. получается на базе после обновления спотыкается на дублирующимся ключе и недозаполняет таблицу.
Где хранится обратная связь ID таблиц с человеческим наименованием?
Чтобы хотя бы попытаться понять что где задублировалось при обновлении.
(40) Спасибо, кончено, но это немного не то.
Значения в таблице _tmpRCT:
Но количество строк странное.
Чуть больше 1 тыс. даже в нормальной базе, хотя таблиц в базе больше 5 тыс.
(33) >я бы и остальные планы обмена так проверил, не только полный
Вот такой код выдает «Да» и в битой базе после обновления, и в нормальной до обновления:
Выяснил, то ошибка с PRIMARY KEY воспроизводится даже на релизе 3.0.64.54, если включить возможность изменений и поменять режим совместимости 8.3.10 => 8.3.12.
При этом реструктуризации подвергаются объекты:
Как раз в следующем за релизом 3.0.64.54 в релизе 3.0.65.69 и меняется режим совместимости.
Но так пока что и не ясно как починить базу до обновления, чтобы изменение режима совместимости при накатывании следующего релиза не ломало базу.
(44)
либо исправить исходные данные, приводящие к ошибке.
Выяснил, что планы обмена изменяются при включении режима совместимости 8.3.11.
Т.е. если включить возможность изменений и просто изменить режим совместимости конфигурации с 8.3.10 на 8.3.11 то баг с ТИИ воспроизводится.
При откате обратно на 8.3.10 бага при ТИИ нет.
Методом последовательного удаления планов обмена из конфигурации выяснил, при снятии с поддержки и удалении только 1 плана обмена УдалитьОбменРозницаБухгалтерия20 баг с ТИИ пропадает.
Т.е. после последующего обновления без этого плана обмена до версии 3.0.65.69 ТИИ базы проходит успешно.
Но проблема обновления в предприятии, описанная в (0), всё еще остается.
(33) >В крайнем случае попробовать на копии удалить все узлы обмена с отключенным контролем целостности и попробовать обновиться.
Удалил обработкой все непредопределенные элементы всех планов обмена (у которых свойство ЭтотУзел = Ложь) перед обновлением.
Та же ошибка после обновления при обработке данных в предприятии.
(36) >как вариант попробуй в файловый вариант сконвертить и там обновить
На файловой базе та же ошибка.
ТИИ и chdbfl и до, и после(!) обновления рапортуют, что проблем нет.
Ответ поддержки 1С, цитата:
(57) Если ты один айтишник который обслуживает организацию и о твоей идее слить базу куда-то (пусть и с целью починить) никто не узнает то можешь делать что угодно.
Я при приеме на работу подписывал бумаги за сохранность коммерческой тайны. И без письменного разрешения начальника отдела ИТ сливать базу куда-то рискуя уголовкой не собираюсь. И начальник отдела тоже в таком случае захочет прикрыть свой зад бумажкой.
В общем, исправления бага я так и не дождался, решил проблему обновления в предприятии правкой кода:
И благополучно обновился до последнего релиза.
ТИИ с исправлением ссылок так и не запускается с ошибкой PRIMARY KEY, но, я думаю, что это ошибка в платформе и когда-нибудь она сама пропадет.
У этой истории неожиданно появилось продолжение.
При попытке загрузки данных из УТ:
(61) Создаете пустую базу из шаблона релиза такого же что и ваша база. Если такого шаблона нет то берете ближайший до этого шаблон и накатываете на него обновления пока не получите базу того же релиза. Если у вас есть изменения в метаданных (как у меня например в справочник контрагентов и договоров добавлены несколько реквизитов) то включаете возможность изменения и добавляете.
После этого обработкой ВыгрузкаЗагрузкаДанныхXML выгружаете все данные из баз источника. Я делаю «все контатанты, все справочники, все документы с движениями». Плюс надо будет дополнительно перенести независимые регистры сведений (по которым движения без регистраторов).
Если во время выгрузки будет происходить ошибка на каких то объектах то просто снимаете галочку на объектах этого вида.
«В процессе обновления информационной базы произошла критическая ошибка
по причине:
В схеме базы данных отсутствует таблица «Reference39».
В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка SDBL:
По структуре БД я определил что Reference39 это Справочник.ДолжностиОрганизаций.
Соответственно выгрузка этого справочника через XML тоже падала и приходилось ее пропускать.
(65) Смотри что получается.
У меня релиз бухгалтерии 2.0.66.65.
Когда запускаю ТИИ под релизом 8.3.13.1513 получаю ошибку
«В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка SDBL:
ТИИ прекрасно проходит.
Обновляем релиз 2.0.66.65 на 2.0.66.67.
Все прекрасно проходит.
Дальше пробую под релизом 8.3.10.2561 перейти на версию 3.0 (обновиться на релиз 3.0.67.54).
Получаю сообщение что для этого нужен релиз не менее 8.3.12
Ставлю его (8.3.12.1714).
Запускаю ТИИ и получаю опять ошибку.
(65) Вообще конечно подход 1С что под релизом 8.3.10.2561 ТИИ проходит без ошибок, а под релизом 8.3.13.1513 ТИИ заканчивается ошибкой удивляет.
Данные же одни и те же.
(65) Попробовал на релизе 8.3.12.1685 который рекомендуется для обновления.
При обновлении в процессе реструктуризации выдает ошибку
«В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка SDBL:
по причине:
Ошибка SDBL:
При этом под релизом 8.3.10.2561 ТИИ проходит без ошибок.
Я у себя решил проблему созданием новой базы из шаблона и переливанием в базу данных.
(71) В общем, поддержка исправила отосланную базу, но инструмент по исправлению (или хотя бы инструкцию) давать отказалась.
Цитирую:
«Восстановить базу пользователь самостоятельно не может, т.к. нужно обновлять также служебные структуры. Мы можем восстановить конкретную проблему, при этом, повторюсь, мы не можем гарантировать что других проблем не будет.»
С учетом того, что они решали проблему 3 месяца, база, которую я им отсылал, стала неактуальной и мне уже нафиг не нужна, тем более, что это не гарантия, что в дальнейшем проблем с ней не будет.
Я решил проблему взятием бэкапа полугодовой давности, в котором точно всё хорошо, и перезаливом данных за полгода из УТ.
Да, возможно бухам придется заново что-то руками подправлять в базе, но это лучше, чем подобный баг вылезет в дальнейшем в исправленной каким-то неведомым способом базе.
Кстати, у меня не взлетели автосгенерированные правила конвертации БП => БП. Справочники еще норм переносило, а на документах вываливалось в ошибку
Не подскажите на будущее как правильно эти правила создавать в конвертации 2.0 или может быть какая-то особенная обработка нужна?
Структура и название таблиц использыемых для хранения данных в БД 1С 8.х
Данные, которые определяют логику функционирования системы на базе 1С:Предприятия, относятся к информационной базе. Хранение информационной базы осуществляется в базе данных с виде набора таблиц, для чего 1С:Предприятие 8.1 может использовать одну из четырех систем управления базами данных (СУБД):
* Встроенную в 1С:Предприятие 8.1 (файловый вариант информационной базы). В этом случае все данные информационной базы хранятся в файле с именем 1Cv8.1CD. Этот файл имеет двоичный формат и по сути является базой данных для встроенной в 1С:Предприятие 8.1 СУБД.
* Microsoft SQL Server (клиент-серверный вариант информационной базы). Все данные информационной базы хранятся в базе данных Microsoft SQL Server.
* PostgreSQL (клиент-серверный вариант информационной базы). Все данные информационной базы хранятся в базе данных PostgreSQL.
* IBM DB2 (клиент-серверный вариант информационной базы). Все данные информационной базы хранятся в базе данных IBM DB2.
На уровне объектов базы данных (таблиц, полей, индексов и т. п.) как файловый так и клиент-серверный вариант информационной базы имеют сходный формат (отличающийся несущественными деталями). Некоторая информация об этом формате содержится ниже.
Вся информационная база представляется в базе данных в виде набора таблиц. Среди них есть несколько таблиц, которые обязательно присутствуют в представлении любой информационной базы:
При старте 1С:Предприятие проверяет наличие в информационной базе перечисленных таблиц и в случае отсутствия какой-нибудь из них выдается сообщение «информационная база разрушена». Отсутствие всех перечисленных таблиц означает, что информационная база пустая. В последнем случае эти таблицы будут созданы.
Перечень и структура других таблиц базы данных определяется конкретной конфигурацией, а именно, определенными в ней объектами метаданных. Имя каждой таблицы состоит из буквенного префикса и следующего за ним номера. Префикс определяет назначение таблицы, а номер позволяет различать таблицы одинакового назначения, относящиеся к разным объектам метаданных. Если в качестве СУБД используется IBM DB2, то описанную структуру имеют не имена таблиц, а их псевдонимы.
Если в конфигурации определен хотя бы один план обмена с установленным флагом «Распределенная информационная база», то будут созданы следующие таблицы:
Ниже перечислены различные объекты метаданных, которым могут соответствовать те или иные таблицы.
При использовании IBM DB2 префиксы псевдонимов таблиц начинаются не с символа подчеркивания, а сразу с буквенной части.
Важно также, чтобы резервное копирование и восстановление базы данных, хранящей информационную базу, выполнялось только целиком. С этой целью рекомендуется использование средств резервного копирования баз данных, встроенных в в используемую СУБД. Резервное сохранение файлового варианта информационной базы может быть выполнено копированием файла 1Cv8.1CD.