Ошибка sdbl не содержится в разделе from

При выполнении каких-либо действий в системе 1С (открытии документа, установки библиотеки, обновлении БД и других смежных операций) пользователь может столкнуться с сообщением «Ошибка SDBL: Таблица или поле configversion не содержится в разделе FROM».  Обычно это связано с техническим сбоем в работе 1С, и лечиться рядом способов, описанных нами ниже. В данном материале мы разберём, в чём суть данной дисфункции, и как её исправить.

Почему возникает ошибка

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

Среди других причин ошибки SDBL также выделяют:

• Использование устаревшей конфигурации или платформы 1С;
• Проблемы с кешом сервера 1С;
• Запуск системы с недостаточными правами (к примеру, от имени учётной записи гостя вместо администратора) и другие причины.

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

Давайте рассмотрим, как исправить ошибку SDBL: Таблица или поле в вашей системе 1С.

Читайте также: как исправить ошибку неверного формата хранилища данных в 1С.

Убедитесь в наличии достаточных прав для запуска системы

Первым делом убедитесь, что вы запускаете вашу систему с правами администратора. Недостаточный уровень прав может приводить к появлению различных проблем при работе с 1С.

Обновите вашу конфигурацию (платформу) 1С

Также проверьте, пользуетесь ли вы самой свежей версией платформы (конфигурации) 1С. При необходимости обновите вашу систему до самой свежей версии продукта. Это может помочь устранить ошибку SDBL с полем configversion в 1С.

Используйте инструмент «Тестирование и исправление».

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

Выгрузите и загрузите файл Dt

Хорошие результаты в избавление от ошибки «поле configversion не содержится в разделе FROM» показал способ, состоящий в выгрузке и последующей загрузке файла Dt (архивной копии базы 1С). Для выгрузки базы зайдите в Конфигуратор, там выберите «Администрирование» , где нажмите на «Выгрузить информационную базу».

Для загрузки выгруженной ранее базы в систему вновь запустите «Конфигуратор», перейдите на вкладку «Администрирование», и в ней активируйте опцию «Загрузить информационную базу». Это может помочь избавиться от ошибки «SDBL: Таблица или поле configversion»

Это интересно: ошибка 2147221164 «Класс не зарегистрирован» в 1С — как решить.

Перезагрузите сервер 1С

Для устранения дисфункции рекомендуем перезагрузить сервер 1С. Перезагрузка указанного сервера обычно выполняется автоматически на протяжении 3-5 минут при условии отсутствия у сервера подключенных пользователей.

Очистите кэш сервера 1С

В некоторых случаях исправить ошибку SDBL можно с помощью очистки кэша сервера 1С. Обычно кэш расположен по адресу:

c:ProgramFiles1cv8srvInforeg_1541

Туда нужно перейти и удалить папки с генерированными именами. Учтите, что кроме кэша в данной папке могут находиться журналы регистрации, а также индекс полнотекстового поиска 1С.

Очистите таблицы в менеджере SQL

Также можно попробовать выполнить очистку таблиц таблицы _ConfigChngR и _ConfigChngR_ExtProps с помощью команды delete.

Вас заинтересует: как устранить дисфункцию «Невозможно создание объекта сервером программирования объектов».

Заключение

В нашем материале мы разобрали причины ошибки «SDBL: Таблица или поле configversion не содержится в разделе FROM» и способы её устранения. Среди всех перечисленных альтернатив хорошую эффективность показал способ с выгрузкой файлов базы данных (файл с расширением Dt), с последующей их повторной загрузкой. Обычно после этого ошибка бывает устранена, и вы сможете пользоваться нормальным функционалом системы 1С.

Специфика современных версий учетных программ обуславливается использованием многоуровневого кода. Логично, что чем сложнее структура — тем выше вероятность возникновения внеплановых ситуаций, с которыми приходится сталкиваться рядовым пользователям конфигурации. В отдельных случаях даже сотрудники администрирующих служб предприятия не всегда способны сразу определить исходную причину появления неполадок, поэтому работа по устранению неудобств может занять немало времени. Одной из наиболее часто встречающихся проблем является классическая ошибка SDBL 1С, источники и способы устранения которой мы и рассмотрим в сегодняшнем обзоре.

Общее представление

Взаимодействуя с учетной программой, пользователи выполняют различные операции, каждая из которых, так или иначе, формирует запрос к базе данных. Создание нового документа, интеграция библиотеки, плановое обновление — во время любого из процессов есть вероятность получить в ответ уведомление от системы, свидетельствующее о том, что одна из логических цепочек была нарушена. Распространенный вариант — когда на экране появляется сообщение об ошибке SDBL 1С ожидается выражение (pos = 6) (а также 15, 57, 198, 250, 469, или любой другой номерной идентификатор).

Фактически это говорит о наличии технического сбоя, с которым чаще всего сталкиваются пользователи, самостоятельно обновляющие конфигурацию автоматическими средствами. Важно понимать, что при работе с программой (и в том числе при установке новых релизов) необходимо иметь определенный уровень навыков и знаний, достаточный для внесения изменений и управления функциональными возможностями платформы.

Впрочем, сильно переживать не стоит. Появление ошибки SDBL 1С еще не значит, что структура базы данных предприятия разрушена полностью — в большинстве случаев исправить проблему можно при помощи стандартного набора способов, реализовать которые под силу даже начинающим пользователям.

Причины возникновения

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

Если говорить об уже упомянутой ранее ошибке SDBL 1С «ожидается выражение (pos = 144)» (или 48, 153, 13 — не столь принципиально), то в этом случае ключевым обстоятельством становится повреждение базы данных, обусловленное нарушением системных логических циклов. К числу распространенных причин возникновения, отмечаемых специалистами, относят не только применение устаревшей конфигурации или платформы, но также и проблемы, связанные с серверным кешем. Кроме того, всегда существует вероятность случайного запуска с некорректной учетной записи, не обладающей достаточным набором прав.

Чаще всего системные ошибки происходят в процессе очередного обновления БД, а также при обращении к ней — через запрос на добавление документов, во время тестовой проверки логической целостности, или же в иных ситуациях. Критической проблемой при установке расширений может стать и «некорректное использование LOCAL/GLOBAL в SET GENERATION», не позволяющее полноценно сохранить базу даже после выборочного удаления. Стоит отметить, что стандартное решение в виде перезагрузки программы обычно не помогает, поэтому для восстановления работоспособности придется воспользоваться альтернативными методиками.

Какие сообщения возникают

Уведомление о технических неполадках отражает специфику возникшей проблемы, и может появиться как во время обновления конфигурации, так и в процессе работы с обменом данных. Как правило, текст в информационном окне раскрывает специфику возникшей ошибки SDBL 1С: «не является именем поля», «ожидается идентификатор» или «выход за пределы размерности результата 1C», и т. д.

Встречаются и вспомогательные приписки, причем их количество зависит от конкретной неточности, допущенной в ходе сборки и настройки обновленного расширения:

• предпринята попытка ввести неприемлемый тип значения «NULL»;

• пропущена точка с запятой;

• нарушение индексирования с полным текстом;

• неоднозначное определение некоторого поля;

• отсутствует выражение (pos =) — с различными числовыми идентификаторами в скобках.

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

Устранение ошибки SDBL 1С

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

В связи с этим главной рекомендацией специалистов является регулярное резервное копирование, позволяющее без особого труда восстановить исходные данные в случае наступления критических обстоятельств. Оптимальный график предусматривает не только ежедневное ночное создание копий, но также и дополнительное резервирование перед каждой значительной операцией, будь то обновление или закрытие периода. Автоматизированная архивация базы реализуется встроенным функционалом учетной программы, а восстановление из Конфигуратора занимает минимум времени, позволяя откатиться к рабочему состоянию практически без прерывания процесса.

Практически любая ошибка SDBL 1С — «недопустимый символ (pos = 40)», «пропущена точка с запятой», или «ожидается имя таблицы 21», может быть устранена путем выполнения несложного набора действий. Перечень доступных вариантов выглядит следующим образом:

1. Удаление кэшированных данных — как на пользовательском рабочем месте, так и на основном сервере, где произошел технический сбой. Для реализации процедуры очистки кэша достаточно закрыть учетную программу, открыть «Проводник», найти, выбрать и удалить набор папок из раздела «Application Data». Отличить нужные элементы проще всего по названию, которое выглядит как хаотичный набор символов — например, «ac5c8bm4-y65k-4s23-a9g8-2dcttp0b15da».

2. Использование функционала Конфигуратора, позволяющего провести тестирование и исправление информационной базы. В этом случае необходимо найти поврежденную ИБ, выбрать ее и перейти в раздел «Администрирование», после чего активировать встроенную функцию для теста и корректировки ошибок.

3. Перезагрузка сервера, на котором расположены программные приложения системы 1С. Самый простой вариант — включение и выключение всех взаимосвязанных SQL-сервисов, включая агент. Для выполнения задачи нужно зайти на нужный серверный источник, выделить агентскую службу, вызвать контекстное меню и остановить процесс. Аналогичные действия повторяем на SQL со служебными процедурами Server и Agent. Повторная активация осуществляется в обратном порядке.

4. Выгрузка БД в отдельный DT-файл с последующей повторной «заливкой». По сути, метод напоминает стандартную перезагрузку системы — структура записывается в файловом формате, что позволяет упорядочить проблемные разделы. Для выполнения процедуры достаточно открыть меню управления учетной программой, найти в категории «Администрирование» функцию «Выгрузить информационную базу», и после ее завершения выбрать опцию «Загрузить ИБ», используя сформированный файл.

5. Откат к последней резервной копии. Один из самых простых и доступных вариантов — конечно, в том случае, если архивирование данных проводится на регулярной основе, а не только перед закрытием периодов. Вообще, решение записывать текущее состояние перед каждым внесением изменений может избавить от большинства проблем, связанных с техническими сбоями. Даже если вы столкнетесь с уведомлением о том, что «ожидается имя поля», или получите ошибку «таблица 1С inforg не создана в новом поколении», источник которой не всегда понятен даже опытным пользователям — загрузка последней копии просто вернет систему к исходному состоянию. Для резервирования допускается использование как SQL MS, так и Конфигуратора учетной программы — через последовательную выгрузку файлов в уже упомянутом DT формате.

6. Обновление платформы через сайт информационно-технологического сопровождения разработчиков, доступный всем лицензированным пользователям продукта. Функционал портала ИТС позволяет установить последнюю редакцию, актуальную на момент обращения, инсталляция которой производится как на основной сервер, так и на рабочие места клиента.

Как правило, один из перечисленных методов позволяет добиться желаемого результата, устраняя проблему в работе учетной системы. В ситуациях, когда применить готовое решение так и не удалось, есть резервный вариант, отличающийся высокой вероятностью успешного исхода. Очистка в менеджере SQL 1С таблиц ConfigChngR и ExtProps, что за последние годы стало уже привычным способом восстановления для большинства специалистов, осуществляется стандартной командой Delete.

На что еще обратить внимание при устранении ошибок SDBL, и как реализовать рассмотренные методы? Сейчас разберемся.

Права доступа

Пожалуй, самая простая причина неполадок, которая тем не менее все еще встречаться на практике — попытка запустить систему через учетную запись, не обладающую соответствующими полномочиями. Убедитесь, что профиль для запуска выбран корректно, чтобы не провоцировать сбои собственными действиями.

Перезагрузка серверов 1С и SQL

Это один из простейших методов восстановления, единственным обязательным условием, для применения которого является выход всех пользователей из базы. Убедившись, что доступ открыт, зайдите на сервер и последовательно выключите агент программы Server и SQL-agent, после чего запустите их в обратном порядке.

Удаление кэшированных данных

Создание кэша представляет собой процесс буферизации информации, используемой базой чаще всего, и, как правило, относящейся к статичной категории. Кэширование позволяет ускорить программный цикл — так, если говорить об учетных системах, оптимизация затрагивает загрузку файлов конфигурации, исключая необходимость постоянного обращения к основному серверу. Однако на практике встречаются случаи некорректной обработки программным обеспечением подобных задач, что в конечном счете становится причиной неправильной работы платформы.

Перечень факторов, обуславливающих нарушение логических циклов, весьма обширен, и охватывает не только динамические обновления системной структуры, но и технические сбои программного или аппаратного характера. В некоторых случаях для устранения ошибки SDBL 1С «ожидается имя поля/таблицы (pos = 21, 45, 48…)» достаточно почистить кэш, сохраненный на сервере, либо на рабочем месте пользователя.

Стандартный путь к месту хранения кэшированных данных выглядит следующим образом:

• «%userprofile%AppDataRoaming1C1Cv8» и «%userprofile%AppDataLocal1C1Cv8» — для операционных систем начиная с Windows 7.

• «%userprofile%Local SettingsApplication Data1C1Cv8» и «%userprofile%Application Data1C1Cv8» — для тех, кто все еще продолжает работать на ХР.

Откройте каталог, расположенный по указанному адресу, выделите и удалите все хранящиеся в нем папки, имя которых представляет собой сгенерированный автоматически набор цифр и букв (вроде «abg7n8ty4-brt9r893-am…»). Стоит отметить, что во время чистки кэша нужно быть особенно внимательными, поскольку в директории также могут находиться поисковый индекс и журналы регистрации 1С, которые не требуют удаления.

Загрузка DT-файла

Этот метод может показаться немного странным, поскольку фактически не предполагает внесения каких-либо корректировок в основную структуру данных. Однако в действительности выгрузка БД в отдельный файл, сохраняемый в формате DT, с последующим обращением к ней же, нередко позволяет восстановить нормальную работу программы. Алгоритм достаточно прост — в режиме Конфигуратора нужно выбрать раздел «Администрирование», использовать опцию «Выгрузить ИБ» (указав каталог для сохранения), после чего повторно залить сформированную базу обратно в систему.

Тестирование и исправление

Еще одна удобная функция, доступная в режиме корректировки конфигурации — встроенный инструментарий, предназначенный для теста и внесения коррективов. В отдельных ситуациях может возникнуть проблема с запуском Конфигуратора — вместо этого можно воспользоваться специальной утилитой chdbfl.exe, представляющей собой упрощенный программный аналог с идентичным функционалом. Приложение находится в каталоге «bin», поэтому найти его не составляет особого труда — как через стандартный путь «C:Program Files (x86)1cv88.3bin», так и через опцию поиска, предлагаемую операционной системой.

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

Обновление платформы

Еще одно простое решение, предусматривающее использование сайта технической поддержки разработчиков 1С. Скачайте дистрибутив актуального релиза, распакуйте архив и активируйте инсталлятор setup.exe — система обновится автоматически.

Очистка таблиц базы данных

Если ни один из вышеперечисленных способов не дал желаемого результата — остается вариант с удалением табличных значений БД, вызывающих появление ошибки, расположенных в каталогах ConfigChngR и ExtProps. Для этого применяется скрипт менеджера SQL, с указанием информационного раздела и командой delete from. В этом случае лучше всего обратиться к профильному специалисту, поскольку некорректное восстановление может привести к более серьезным последствиям.

Заключение

Автоматизация учетных процессов — важный аспект, позволяющий оптимизировать работу компании. Ошибки SDBL 1С встречаются достаточно часто, поэтому стоит заранее позаботиться об оперативном устранении возможных проблем. Мобильные решения, предлагаемые компанией «Клеверенс», гарантируют квалифицированную поддержку, а также помогут решить задачи, связанные с учетом данных на предприятии.

Количество показов: 7387

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

Окно с данной ошибкой 1С имеет дополнительное содержание. Типичные сообщения:

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

Исправление ошибки SDBL

Большая часть способов исправления связана с восстановлением нормальной работы Информационной Базы. Но иногда описанными способами решить проблему не получается, поэтому помните о самом лучшем, универсальном способе — регулярном резервном копировании.

Перезагрузка сервера 1С и SQL-сервера

Самый простой способ, при условии, что на текущий момент в базе никто не работает.

Зайдите на сервер и выключите следующие службы:

• «Агент сервера 1С»,
• «SQL Server»,
• «Агент SQL Сервера».

А затем запустите их обратно.

Очистка кэша на сервере и клиента, где проявилась ошибка

В некоторых случаях исправить ошибку SDBL можно с помощью очистки кэша сервера 1С.

Как правило кэш расположен по адресу:

• «%userprofile%Local SettingsApplication Data1C1Cv8» и «%userprofile%Application Data1C1Cv8» для Windows XP,
• «%userprofile%AppDataRoaming1C1Cv8» и «%userprofile%AppDataLocal1C1Cv8» для Windows 7 и выше.

Перейдите в данный каталог и удалить все папки с генерированными именами вида « dg7c8re4-b89r…». При удалении будьте внимательны — в этой директории может присутствовать индекс полнотекстового поиска 1С, а также журналы регистрации, их удалять не нужно.

Перезаливка базы из DT-файла

Иногда помогает, казалось бы, парадоксальный способ — выгрузка базы данных в файл формата DT, а затем загрузка его обратно.

Войдите в режим «Конфигуратор», выберите пункт меню «Администрирование» > «Выгрузить информационную базу» и выберите каталог для сохранения файла.

Затем через аналогично через меню «Администрирование» > «Загрузить информационную базу» загрузите его обратно.

Тестирование и исправление Информационной базы

Для тестирование и исправление Информационной базы: войдите в «Конфигуратор», выберите пункт меню «Администрирование» > «Тестирование и исправление».

В случаях, когда невозможно запустить конфигуратор, воспользуйтесь утилитой chdbfl.exe. Это упрощенная программа-аналог тестирования базы, функции, которая запускается в режиме конфигуратора. Расположена она в папке «bin» установленной технологической платформы, например, C:Program Files (x86)1cv88.3…binchdbfl.exe.

Пользоваться ей просто — указываете путь к файлу базы данных и ставите опцию, нужно ли сразу исправлять обнаруженные ошибки. Если нет — утилита только продиагностирует ИБ.

Обновление платформы до новой версии

В данном случае всё достаточно просто. Скачивает с сайта поддержки 1С дистрибутив свежей версии платформы, распаковываем и запускаем инсталятор setup.exe.

Очистка таблиц базы данных

В крайнем случае можно попробовать удалить таблицы БД, связанные с ошибкой — «dbo._ConfigChngR» и «dbo._ConfigChngR_ExtProps».

Производится это через менеджер SQL-скриптом вида:
use имя_базы_данных
delete from dbo ._ ConfigChngR
delete from dbo ._ ConfigChngR _ ExtProps

Помните, прямые SQL-запросы лучше доверить профессионалу, умеющему работать с SQL.

Содержание:

1.       Возникновение ошибки SDBL

2.       Устранение ошибки SDBL в 1С

Приветствую, коллеги! В данной статье будет рассмотрена знакомая и набившая оскомину многим специалистам 1С ошибка SDBL, а также возможные пути её устранения.  

1.    Возникновение ошибки SDBL

Ошибка SDBL возникает, когда происходит обновление конфигурации 1С:Предприятие или сохранение перемен. Также сообщение об ошибке может возникать при работе с обменами данных:

Рис. 1 Сообщения 1С об ошибке SDBL

Также к данным сообщениям часто есть одна или несколько приписок:

·        была совершена попытка вставить значение с недопустимым типом;

·        был совершён пропуск точки с запятой;

·      имеет место ошибка, которая произошла при индексировании с полным текстом;

·        некоторое поле имеет неоднозначное определение;

·        не хватает выражения (pos =);

·        совершён выход из размерностей;

·        в поле таблицы используется невозможный тип значения «NULL».

Обратите внимание: есть вероятность, что при ошибке будут другие сообщения, не указанные выше!  

2.    Устранение ошибки 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.

Специалист компании «Кодерлайн»

Айдар Фархутдинов

При выполнении каких-либо действий в системе 1С (открытии документа, установки библиотеки, обновлении БД и других смежных операций) пользователь может столкнуться с сообщением «Ошибка SDBL: Таблица или поле configversion не содержится в разделе FROM».  Обычно это связано с техническим сбоем в работе 1С, и лечиться рядом способов, описанных нами ниже. В данном материале мы разберём, в чём суть данной дисфункции, и как её исправить.

Почему возникает ошибка

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

Среди других причин ошибки SDBL также выделяют:

• Использование устаревшей конфигурации или платформы 1С;
• Проблемы с кешом сервера 1С;
• Запуск системы с недостаточными правами (к примеру, от имени учётной записи гостя вместо администратора) и другие причины.

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

Давайте рассмотрим, как исправить ошибку SDBL: Таблица или поле в вашей системе 1С.

Читайте также: как исправить ошибку неверного формата хранилища данных в 1С.

Убедитесь в наличии достаточных прав для запуска системы

Первым делом убедитесь, что вы запускаете вашу систему с правами администратора. Недостаточный уровень прав может приводить к появлению различных проблем при работе с 1С.

Обновите вашу конфигурацию (платформу) 1С

Также проверьте, пользуетесь ли вы самой свежей версией платформы (конфигурации) 1С. При необходимости обновите вашу систему до самой свежей версии продукта. Это может помочь устранить ошибку SDBL с полем configversion в 1С.

Используйте инструмент «Тестирование и исправление».

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

Выгрузите и загрузите файл Dt

Хорошие результаты в избавление от ошибки «поле configversion не содержится в разделе FROM» показал способ, состоящий в выгрузке и последующей загрузке файла Dt (архивной копии базы 1С). Для выгрузки базы зайдите в Конфигуратор, там выберите «Администрирование» , где нажмите на «Выгрузить информационную базу».

Для загрузки выгруженной ранее базы в систему вновь запустите «Конфигуратор», перейдите на вкладку «Администрирование», и в ней активируйте опцию «Загрузить информационную базу». Это может помочь избавиться от ошибки «SDBL: Таблица или поле configversion»

Это интересно: ошибка 2147221164 «Класс не зарегистрирован» в 1С — как решить.

Перезагрузите сервер 1С

Для устранения дисфункции рекомендуем перезагрузить сервер 1С. Перезагрузка указанного сервера обычно выполняется автоматически на протяжении 3-5 минут при условии отсутствия у сервера подключенных пользователей.

Очистите кэш сервера 1С

В некоторых случаях исправить ошибку SDBL можно с помощью очистки кэша сервера 1С. Обычно кэш расположен по адресу:

c:ProgramFiles1cv8srvInforeg_1541

Туда нужно перейти и удалить папки с генерированными именами. Учтите, что кроме кэша в данной папке могут находиться журналы регистрации, а также индекс полнотекстового поиска 1С.

Очистите таблицы в менеджере SQL

Также можно попробовать выполнить очистку таблиц таблицы _ConfigChngR и _ConfigChngR_ExtProps с помощью команды delete.

Вас заинтересует: как устранить дисфункцию «Невозможно создание объекта сервером программирования объектов».

Заключение

В нашем материале мы разобрали причины ошибки «SDBL: Таблица или поле configversion не содержится в разделе FROM» и способы её устранения. Среди всех перечисленных альтернатив хорошую эффективность показал способ с выгрузкой файлов базы данных (файл с расширением Dt), с последующей их повторной загрузкой. Обычно после этого ошибка бывает устранена, и вы сможете пользоваться нормальным функционалом системы 1С.

   bavkyz

14.10.19 — 15:59

   unenu

1 — 14.10.19 — 16:03

   bavkyz

2 — 14.10.19 — 16:08

   Amra

3 — 14.10.19 — 16:18

Есть тестовая 8.3.12, попробуйте на копии обновится и поиграться

   bavkyz

4 — 14.10.19 — 16:19

(3) ок, попробую.

   Провинциальный 1сник

5 — 14.10.19 — 16:20

(1) В новой БП уже хотят (рекомендуют) платформу 8.3.14 или новее.

   Amra

6 — 14.10.19 — 16:22

(5) А причем тут платформа? Речь о конфигурации

   Amra

7 — 14.10.19 — 16:23

(4) Тьфу, то есть 3.1.12

   Amra

8 — 14.10.19 — 16:23

И да, какая платформа?

   bavkyz

9 — 14.10.19 — 16:38

   2S

10 — 14.10.19 — 16:40

может ТиИ сделать перед обновлением?

   bavkyz

11 — 14.10.19 — 16:41

(10) Не помогает ТиИ.

   Amra

12 — 14.10.19 — 16:46

(9) 13 платформа не рекомендуется самой фирмой 1С. Или откатись на 12, или апгрейдься на 14. Я бы начал с этого

   bavkyz

13 — 14.10.19 — 16:48

(12) ок, попробую.

   bavkyz

14 — 14.10.19 — 17:59

оооо) вышла 3.1.11.108 попробую обновиться

   МихаилМ

15 — 14.10.19 — 19:00

есть решение. ищите в форуме по фразе » Для одного ссылочного кода существует более одной таблицы в базе данных»

   palsergeich

16 — 14.10.19 — 20:08

https://bugboard.v8.1c.ru/error/000051158https://bugboard.v8.1c.ru/error/000051158

Есть такая бага.

Для тех у кого нет доступа: при разворачивании из sql бекапа сбиваются номера таблиц в кластере.

Все релизы с 12 по 15 платформы до определенного релиза ее имеют. За последние 2 недели уже 2 случая когда только обновление платформы помогает

   palsergeich

17 — 14.10.19 — 20:11

По крайней мере при ней срет такими же сообщениями

   palsergeich

18 — 14.10.19 — 20:22

Они там сдрамматизировали в описании, а по факту случая2:

— Реструктуризация проходит успешно, но в пользовательском режиме уизмененных объектов при добавлении / открытии карточки вылазит сообщение с Ошибка SDBL: бла бла бла

— Реструктуризация отваливается с ошибкой Ошибка SDBL: бла бла бла, при этом в пользовательском режиме все прекрасно работает, и изменения без реструктуризации тоже.

   bavkyz

19 — 15.10.19 — 05:06

(16) установил новую платформу 8.3.15.1700, файловая база , ошибки имеют место быть …. попробую ТиИ сделать.

   DrZombi

20 — 15.10.19 — 07:48

(19) платформа 8.3.14.1779, таки нет такой ошибки

А вы делали бекапы? Может того, обратно вернуться?

   Провинциальный 1сник

21 — 15.10.19 — 08:01

(16) А какая может быть связь с восстановлением из sql-бэкапа и номерами таблиц в кластере? Базе же восстанавливается целиком и полностью. Если конечно это не постгрес, там получить невосстановимый бэкап крайне просто…

   lopus

22 — 15.10.19 — 08:24

Не давно только решал такую проблему на удаленной точке. Думаю правда здесь ситуация другая. Но в процессе исследования нашел, что такая ошибка «Таблица или поле ID не содержится в разделе FROM» присуща одной из версий платформы. Исправлена в одном из релизов 8.3.15

   Провинциальный 1сник

23 — 15.10.19 — 08:37

А, понял.. Проблема в том, что некоторые параметры информационной базы (в частности счетчик метаданных) хранятся в памяти кластера. Вообще непонятна логика такого решения. Лучше бы реализовали хранение метаданных в развернутом виде в таблицах, а не в виде блобов, которые надо сначала загрузить в память сервера.

   bavkyz

24 — 15.10.19 — 12:38

(20) Бекапы базы есть, но ситуация вызвала интерес и хочется решить без восстановления бекапа и повторного ввода утерянных данных заново…

   bavkyz

25 — 15.10.19 — 12:39

Попробую ночером ребутнуть сервер 1С и SQL

   Йохохо

26 — 15.10.19 — 12:44

(25) Вы внимательно прочитали (23) перед ребутом?

   Провинциальный 1сник

27 — 15.10.19 — 12:45

(25) sql то зачем?

   bavkyz

28 — 15.10.19 — 12:53

   Провинциальный 1сник

29 — 15.10.19 — 13:00

   Провинциальный 1сник

30 — 15.10.19 — 13:14

+(29) А на каминовском форуме советуют ТиИ с галочкой «реструктуризация» запустить.

   bavkyz

31 — 15.10.19 — 19:04

(30) делал, не помогло.

   bavkyz

32 — 16.10.19 — 09:12

Откатил базу назад, и остался на 3.1.10.174. На 3.1.11 пока не перехожу. Либо пока платформу на 8.3.15.1700 не перейду…. думаю там проблем не будет.

   Провинциальный 1сник

33 — 16.10.19 — 09:13

(32) А есть инфа, что именно в 1700 этот баг исправлен?

   dka80

34 — 16.10.19 — 09:21

3.1.11.108 КОРП, платформа 8.3.12.1855 — полет нормальный

   Йохохо

35 — 16.10.19 — 09:21

(33) думаешь 1с внедрило регрессию для ошибок? )

   Фрэнки

36 — 16.10.19 — 09:30

   Провинциальный 1сник

37 — 16.10.19 — 09:50

   Фрэнки

38 — 16.10.19 — 10:01

(37) Я не воспроизвел это баг. Т.е. у меня не было умысла его 100% воспроизвести, но обновление платформы (только не везде, а на отдельно взятых местах) не спровоцировало появления бага. Т.е. повторяюсь — это // сочетание накопившихся //

   Провинциальный 1сник

39 — 16.10.19 — 10:05

(38) Я так понимаю, что баг проявляется при восстановлении средствами sql базы, в которой перед бэкапом было добавление метаданных, поверх базы, в которой этого добавления не было. В этом случае последующее добавление метаданных вызывает конфликт нумерации, если после загрузки из  бэкапа не рестартовать сервер 1с.

   Фрэнки

40 — 16.10.19 — 10:07

ну да, как-то так

   Ёпрст

41 — 16.10.19 — 13:40

(33) не исправлен

   Ёпрст

42 — 16.10.19 — 13:41

в  8.3.15.1700 словили туже ошибку в перефирийной базе. хотя цент норм обновился. Пришлось откатиться на 8.3.13.1690

   Провинциальный 1сник

43 — 16.10.19 — 14:05

Короче, надо на стенке записать — после восстановления из бэкапа или перед внесением изменения в конфигурацию (обновлением) нужно обязательно рестартовать сервер 1с. Пока официально не будет объявлено о том, что баг исправлен.

   DrZombi

44 — 16.10.19 — 14:13

(0) Пока вы тут это обсуждали, уже вышло обновление 3.1.11.108

   DrZombi

45 — 16.10.19 — 14:15

(43) Просто рестарт чинить сею ошибку? Оригинально — «Попробуйте Выключить и Включить» (сериал Компьютерщики)

   Провинциальный 1сник

46 — 16.10.19 — 15:26

(45) Просто счетчик метаданных, вызывающий проблему, хранится в памяти сервера. И рестарт естественно его обнуляет.)

   Йохохо

47 — 16.10.19 — 16:15

(46) а не в рантайме его вычислить нельзя потому, что расширения, забавно

   Провинциальный 1сник

48 — 16.10.19 — 16:19

(47) Как расширения мешают тому, чтобы хранить счетчик метаданных непосредственно в базе и брать его оттуда непосредственно всякий раз, когда он нужен? Это просто сделали в целях оптимизации и «недодумали».

(48) наверняка точек входа в трансляцию на скуль очень много, мб это заплатка, причем на годы

У меня была похожая ситуация. Вот ответ 1С: 
Вероятно вы на версии платформы 8.2.13 обновили конфигурацию БП на версию 2.0.42.5, после чего при обновлении платформы на версию 8.2.16.368 или выше при запуске базы после конвертации происходит ошибка SDBL. 
Способ обхода сначала обновить платформу, сконвертировать ИБ, и только после этого обновляться на 2.0.42 

Если обновление конфигурации на 2.0.42.5 выполнялось на 8.2.13, то режим совместимости оказался с 8.2.16, а изменения структуры таблиц БД, которую сделала бы 8.2.16 при смене режима совместимости, не произошло, т.к. 13-й релиз этого не умеет. Таким образом, если далее запускается платформа 16-го релиза, то она считает, что изменение структуры таблиц уже выполнено, хотя этого не произошло. Это и приводит к описанному эффекту. Как обойти: сначала обновить платформу, сконвертировать ИБ, и только после этого обновляться на 2.0.42; либо 1. Открыть 13-м релизом Конфигуратора 2. Сохранить конфигурацию в файл 3. понизить режим совместимости до 8.1, реструктуризовать 4. установить режим совместимости «Не используется», реструктуризовать 5. Закрыть Конфигуратор 13-го релиза, открыть Конфигуратор 16-го. 6. Выполнить загрузку конфигурации из файла, реструктуризоваться.

Решение отсюда:

В общем исправил(ось), так что если кому нужно — на заметку. 
Так как dt  смог выгрузиться, то попробовал его залить в старую версию 1с 8.2 
Взял 8.2.13.249, создал пустую и закинул туда этот дт-шник. Конфа встала, но при запуске ругалась уже не на критические ошибки ИБ, а на код (значит как минимум началась отладка). После чего принудительно снял с поддержки и накатил конфигурацию 11.0.6.9. Конфигурация встала. дальше запустил под этой же версией 1с 8.2 ИБ — запустилось. 
Перезашёл в конфиг под 8.2.15.289, перевёл, запустил ИБ — и вуа ля, база жива и здорова. Что это было — знают только разрабы. Но если вдруг кому пригодиться — буду рад (хоть не будете тра..ть мозг как я)


Для базовой версии отсюда:


Вот дополненная, так сказать, версия инструкции по решению данной проблемы с базовой конфигурацией: 
(работа выполнялась на конфигурации БП 2.0.45.6 и с помощью платформ 8.2.13.219 и 8.2.16.368) 

1. Открыть 13-м релизом Конфигуратора; 
2. Сохранить не снятую с поддержки конфигурацию в файл; 
3. Снять конфигурацию с поддержки, сохранить конфигурацию, обновить конфигурацию базы данных; 
3. Понизить режим совместимости до 8.1, сохранить конфигурацию, обновить конфигурацию базы данных, реструктуризовать; 
4. Установить режим совместимости «Не используется», сохранить конфигурацию, обновить конфигурацию базы данных, реструктуризовать; 
5. Закрыть Конфигуратор 13-го релиза, открыть Конфигуратор 16-го. 
6. Выполнить загрузку конфигурации из файла, сохранить конфигурацию, обновить конфигурацию базы данных, реструктуризоваться. 

Единственное отступление от этой инструкции, которое я сделал, так это загружал в п.6 файл, полученный из чистой 45,6, сделанной на 13-й платформе.

Прошло немало времени, и все же хотелось бы продолжить и поделиться мало ли кому поможет.

Текущая платформа 1С 8.3.13.1690, все остальные технические параметры остались прежними и ничего не менялось.

(экспериментировать с другими версиями платформы не стал, так как на этой версии сидим давно и вроде бы все работало же….)

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

Месяц назад, после очередной такой реструктуризации которая прошла штатно поломалась часть объектов (при чем уже более значительная, открытие которых в режиме 1С приводило к SDBL разного рода), час икс настал благо это случилось в выходной день. Откат базы к бэкапу недельной давности, наращивание логами транзакции до момента поломки. Выгрузка в DT которая кстати проходит штатно как и выгрузка CF как и загрузка того и другого обратно.

Поднял тестовую базу и начал экспериментировать (на боевой запретил все регламенты по реструктуризации и пересчетам итогов по выходным), в итоге пришлось полностью убить все имеющиеся планы обмена (выгрузка CF удаление всех планов обмена, сравнением объединение с CF чтобы планы обмена вернулись обратно и до настройка их в 1С), так как оказалось в них откуда то взялись данные зарегистрированные для узла ЭтотУзел (подозреваем это привнесла одна из платформ так как там находилась часть данных а не все что могло бы туда попасть за прошлые года). Пришлось лишиться записей в регистре сведений «История изменений» — самопальный механизм которые регистрировал любые настроенные изменения любых настроенных объектов (изменения реквизитов или табличных частей) — в этом регистре были сотни миллионов записей, штатно очистить не представлялось возможным из за недостатка времени, поэтому TRUNCATE TABLE на SQL решил проблему моментально.

После долгих мучений в итоге (спасибо предыдущему посту про обновление на сервере) конфигурация была снята с режима совместимости 8.3.10 и обновлена на сервере (не через штатную кнопку обновления — через штатную крашилось при реструктуризации), что прошло в принципе достаточно быстро, далее открытие режима 1С предприятия, проверка всех объектов — все работает (чудо не иначе). Возвращаемся в конфигуратор, реструктуризация через ТиИ — все проходит.

Что это было остается догадываться, возможно оно до сих пор сидит в базе, но сейчас все работает.

Всем удачи я поделился исключительно своим опытом и своими «колдобинами» при мучении с базой объемом под 300 гб, и не настаиваю что всем это поможет, но в друг кому то пригодится .