Ошибка SDBL: Таблица или поле не содержится в разделе FROM
Добрый день. Много тем поднималось с похожими вопросами но пути решения все разные и неоднозначные. Хотелось бы еще поднять этот вопрос для устранения ошибки и понимания, что это за ошибка и как с ней бороться.
Платформа 1С:Предприятие 8.2 (8.2.19.90), Конфигурация давно снята с поддержки и очень сильно переписанная, подключена к хранилищю.
В очередной доработке был добавлен реквизит Сумма_2 Число(15,2) в ТЧ "Товары" Докумената "Реализация ТиУ". В тестовой базе все работало нормально. При обновлении основной базы возникла ошибка. Когда я открываю документ "Реализация ТиУ" вываливается ошибка Ошибка SDBL: Таблица или поле не содержится в разделе FROM
Как исправить и почему они возникают такие ошибки мне не понятно?
Платформа 1С:Предприятие 8.2 (8.2.19.90), Конфигурация давно снята с поддержки и очень сильно переписанная, подключена к хранилищю.
В очередной доработке был добавлен реквизит Сумма_2 Число(15,2) в ТЧ "Товары" Докумената "Реализация ТиУ". В тестовой базе все работало нормально. При обновлении основной базы возникла ошибка. Когда я открываю документ "Реализация ТиУ" вываливается ошибка Ошибка SDBL: Таблица или поле не содержится в разделе FROM
Как исправить и почему они возникают такие ошибки мне не понятно?
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(3) Да, я скопировал реквизит справочника в ресурс РС - получил SDBL: 1с таблица или поле ir2 не содержится в разделе from
Создал ресурс руками - всё починилось.
Видимо, при копировании полей, с полями копируются не только нужные параметры (наименование, тип данных), но и параметры, которые соответствуют исходному полю, что не всегда нужно.
Создал ресурс руками - всё починилось.
Видимо, при копировании полей, с полями копируются не только нужные параметры (наименование, тип данных), но и параметры, которые соответствуют исходному полю, что не всегда нужно.
Есть одна изощренная идея. Сделайте план обмена - распределенную информационную базу. Так вы потенциально сможете создать копию базы. Поскольку посередине все сохраняется в XML, но новая будет делаться начисто, и должна уже без ошибок полей.
Пишу через время. Ничего не спасло взяли старый бекап (месячной давности) и в него из битой базы перенесли данные через XML. Повезло, что побился регистр сведений и просто перепровели перенесенные документы и стало все хорошо.
(8) Да, я скопировал реквизит справочника в ресурс РС - получил SDBL: 1с таблица или поле ir2 не содержится в разделе from
Создал ресурс руками - всё починилось.
Видимо, при копировании полей, с полями копируются не только нужные параметры (наименование, тип данных), но и параметры, которые соответствуют исходному полю, что не всегда нужно.
Создал ресурс руками - всё починилось.
Видимо, при копировании полей, с полями копируются не только нужные параметры (наименование, тип данных), но и параметры, которые соответствуют исходному полю, что не всегда нужно.
можно тут отпишусь, мож кому пригодится. почти типовая БПКорп:
Ошибка SDBL: Таблица или поле DataSeparationUse1797 не содержится в разделе FROM (1797-цыфры могут быть разные)
поле DataSeparationUseXXX сидит в 12 таблицах:
1.ODataSettings 1
2. CommonSettings 1
3, RepSettings 1
4, RepVarSettings 1
5, FrmDtSettings 1
6, DynListSettings 1
7, UsersWorkHistory 1
8, SystemSettings 1
9, ExtensionsInfo
10, ExtensionsInfoNGS
11, ExtensionsRestruct
12, ExtensionsRestructNGS
тестирование, выгрузка/загрузка, смена платформы ничо не дали.
почитал тута :
_DataSeparationUse<n> – использование разделения данных,
за разделение отвечают два штатных общих реквизита ОбластьДанныхВспомогательныеДанные и ОбластьДанныхОсновныеДанные.
отключил у них использование для разделения данных (снова попробовал обновить - барада), включил использование - и ура
Ошибка SDBL: Таблица или поле DataSeparationUse1797 не содержится в разделе FROM (1797-цыфры могут быть разные)
поле DataSeparationUseXXX сидит в 12 таблицах:
1.ODataSettings 1
2. CommonSettings 1
3, RepSettings 1
4, RepVarSettings 1
5, FrmDtSettings 1
6, DynListSettings 1
7, UsersWorkHistory 1
8, SystemSettings 1
9, ExtensionsInfo
10, ExtensionsInfoNGS
11, ExtensionsRestruct
12, ExtensionsRestructNGS
тестирование, выгрузка/загрузка, смена платформы ничо не дали.
почитал тута :
_DataSeparationUse<n> – использование разделения данных,
за разделение отвечают два штатных общих реквизита ОбластьДанныхВспомогательныеДанные и ОбластьДанныхОсновныеДанные.
отключил у них использование для разделения данных (снова попробовал обновить - барада), включил использование - и ура
(9)
появилась такая же ошибка при обновлении, и хотел бы наверное уточнить что мне помогло
как оказалось реально проблема в двух реквизитах
ОбластьДанныхВспомогательныеДанные
ОбластьДанныхОсновныеДанные
что конкретно сделал,
1. открыл конфигурацию именно БД,
2. ручками выставил свойства у этих реквизитов в текущей (не сохраненной), точно такие же, как и в конфигурации БД,
3. после чего все отлично сохранилось,
4. далее вернул свойства этих реквизитов к тем, при которых валилась ошибка, снова сохранил, в этот раз все без ошибок.
DataSeparationUse
появилась такая же ошибка при обновлении, и хотел бы наверное уточнить что мне помогло
как оказалось реально проблема в двух реквизитах
ОбластьДанныхВспомогательныеДанные
ОбластьДанныхОсновныеДанные
что конкретно сделал,
1. открыл конфигурацию именно БД,
2. ручками выставил свойства у этих реквизитов в текущей (не сохраненной), точно такие же, как и в конфигурации БД,
3. после чего все отлично сохранилось,
4. далее вернул свойства этих реквизитов к тем, при которых валилась ошибка, снова сохранил, в этот раз все без ошибок.
Такая ошибка появилась при попытке обновить конфигурацию БД после загрузки типовой БП корп из cf на платформе 8.3.13, выгрузка с платформы 8.3.12.
Решение было таким: в настройках поддержки включить возможность изменения, снять с поддержки все константы, загрузить еще раз cf, обновить конфигурацию БД
Решение было таким: в настройках поддержки включить возможность изменения, снять с поддержки все константы, загрузить еще раз cf, обновить конфигурацию БД
У меня после добавления документа в типовую ERP вываливалась ошибка: Таблица или поле Number не содержится в разделе FROM.
Решил проблему при помощи запуска в режиме предприятия с ключом: /С ЗапуститьОбновлениеИнформационнойБазы
Решил проблему при помощи запуска в режиме предприятия с ключом: /С ЗапуститьОбновлениеИнформационнойБазы
Такую ошибку получил при тестировании базы на проверке логической целостности.
Chdbfl ошибок не находил.
Конфигурация типовая, возможность изменения не включена. Платформа 1С:Предприятие 8.3 (8.3.13.1644).
Помогло следующее:
1. Зашел в Конфигурация - поддержка - настройка поддержки.
2. Сохранил конфигурацию в файл.
3. Тут же включил возможность изменения, снял с поддержки.
4. Загрузил конфигурацию из файла.
Тестирование прошло, была одна ошибка: "Документ не зарегистрирован в журнале ОбщийЖурналДокументов. Создана новая запись в журнале"
База открывается (она и раньше открывалась), полет нормальный.
Chdbfl ошибок не находил.
Конфигурация типовая, возможность изменения не включена. Платформа 1С:Предприятие 8.3 (8.3.13.1644).
Помогло следующее:
1. Зашел в Конфигурация - поддержка - настройка поддержки.
2. Сохранил конфигурацию в файл.
3. Тут же включил возможность изменения, снял с поддержки.
4. Загрузил конфигурацию из файла.
Тестирование прошло, была одна ошибка: "Документ не зарегистрирован в журнале ОбщийЖурналДокументов. Создана новая запись в журнале"
База открывается (она и раньше открывалась), полет нормальный.
Была рабочая конфа, в разработке не первый год уже.
Создаю в давно знакомом конфигураторе справочник, добавил ему ТЧ и пару реквизитов ручками, один скопировал с существующего справочника. Запускаю - "не найдено поле ID".
Копирую справочник в дереве метаданных, запускаю предприятие - та же ситуация с копией.
Создаю третий справочник, все реквизиты создаю ручками, но точно такие же, как у предыдущих двух. Запускаю - работает.
Вероятно, при копировании реквизита из существующего объекта он как-то криво обрабатывался платформой и не создавался в SQL.
Создаю в давно знакомом конфигураторе справочник, добавил ему ТЧ и пару реквизитов ручками, один скопировал с существующего справочника. Запускаю - "не найдено поле ID".
Копирую справочник в дереве метаданных, запускаю предприятие - та же ситуация с копией.
Создаю третий справочник, все реквизиты создаю ручками, но точно такие же, как у предыдущих двух. Запускаю - работает.
Вероятно, при копировании реквизита из существующего объекта он как-то криво обрабатывался платформой и не создавался в SQL.
Поделюсь опытом или мнением - переход БУХ (Укр) с 2.0 (БСП 2.1) на БУХ 2.1 (БСП 3.0.1).
Изменений в обновлении было прилично.
После обычного объединения тоже поймали ошибку "Ошибка SBDL - Таблица или поле DataSeparationUse11111 не содержится в разделе FROM".
Анализ показал, что при удалении объектов как-то криво удаляются ссылки на них из состава Общих реквизитов.
Удалил руками объекты нужные (объединяемся без общих реквизитов и платформа сама подскажет ЧТО надо почистить), сохранился - без ошибок, объединил ещё раз целиком и всё заработало.
Изменений в обновлении было прилично.
После обычного объединения тоже поймали ошибку "Ошибка SBDL - Таблица или поле DataSeparationUse11111 не содержится в разделе FROM".
Анализ показал, что при удалении объектов как-то криво удаляются ссылки на них из состава Общих реквизитов.
Удалил руками объекты нужные (объединяемся без общих реквизитов и платформа сама подскажет ЧТО надо почистить), сохранился - без ошибок, объединил ещё раз целиком и всё заработало.
Делали перевод с нетиповой конфигурации Бухгалтери 2.0 на типовую Бухгалтерию 3.0 с постановкой на поддержку. Работали в файловом варианте базы.После завершени - перенесли на сервер и заодно его обновили .. и завертелось..
В файловом варианте работала -загрузили на сервер - сразу при входе в базу валится ошибка и ничего не дает сделать.
Тестирование и исправление - пустая трата времени.(все идеально -ошибок нет)
Выгрузка в DT - загрузка - тоже самое.
Решение которое помогло мне :
Удалили Платформу 8.3.18.1289 и поставил 8.3.17.1851 - Проблема сразу исчезла.
При первом входе появился вопрос о перемещении базы - подозреваю,что именно этот механизм на новой платформе и валит базу.т.к это один из механизмов ,который стартует при первом запуске после выявления факта переноса базы.
Вывод : проблема в платформе 8.3.18.1289 - не теряйте время - откатывайтесь на релиз ниже.
В файловом варианте работала -загрузили на сервер - сразу при входе в базу валится ошибка и ничего не дает сделать.
Тестирование и исправление - пустая трата времени.(все идеально -ошибок нет)
Выгрузка в DT - загрузка - тоже самое.
Решение которое помогло мне :
Удалили Платформу 8.3.18.1289 и поставил 8.3.17.1851 - Проблема сразу исчезла.
При первом входе появился вопрос о перемещении базы - подозреваю,что именно этот механизм на новой платформе и валит базу.т.к это один из механизмов ,который стартует при первом запуске после выявления факта переноса базы.
Вывод : проблема в платформе 8.3.18.1289 - не теряйте время - откатывайтесь на релиз ниже.
(24) Решение простое и эффективное!
Помогло с БП 3.0.103.21
Была выгрузка в .dt с платформы 8.3.18
Ошибка при запуске базы SDBL:\nТаблица или поле DataSeparationUseN не содержится в разделе FROM
Поставил 8.3.17, проверил загрузку в базу - ОК, потом в конфигуратор и повторная выгрузку в .dt
Поставил 8.3.20, загрузил .dt, все работает!
Спасибо!
Помогло с БП 3.0.103.21
Была выгрузка в .dt с платформы 8.3.18
Ошибка при запуске базы SDBL:\nТаблица или поле DataSeparationUseN не содержится в разделе FROM
Поставил 8.3.17, проверил загрузку в базу - ОК, потом в конфигуратор и повторная выгрузку в .dt
Поставил 8.3.20, загрузил .dt, все работает!
Спасибо!
Долбоящеры 1С если у вас под новый год клинит мозг и вы не способны выпускать релизы без косяков не работайте сук....а не портите праздники другим. Это не первый раз когда эти кривокодеры выпускают гавнокод под новый год.
мда...
самое смешное, что трабла с этой ошибкой в реальности не связана с обновлением именно конфигурации, а связана с заменой релиза платформы. Но! Просто после обновления платформы пытаются накатить обновление конфигурации и тут возникшая от платформы ошибка вылазит во всей красе.
Т.е. надо после обновления платформы устранить возникшие ошибки (неочевидные)
И уже после их устранения пытаться конфы обновлять.
самое смешное, что трабла с этой ошибкой в реальности не связана с обновлением именно конфигурации, а связана с заменой релиза платформы. Но! Просто после обновления платформы пытаются накатить обновление конфигурации и тут возникшая от платформы ошибка вылазит во всей красе.
Т.е. надо после обновления платформы устранить возникшие ошибки (неочевидные)
И уже после их устранения пытаться конфы обновлять.
Данная ошибка может быть при получении итогов регистра бухгалтерии с отбором по счету, значению субконто, корсчету и виду кор.субконто (в Анализе счета, например), только в клиент-серверном варианте.
Код ошибки в bugboard 50014467.
Исправлена: "Технологическая платформа", версия 8.3.19.1522
Исправлена: "Технологическая платформа", версия 8.3.20.1710
Исправлена: "Технологическая платформа", версия 8.3.21.1141 (для тестирования)
Если бы bugboard 1С нормально индексировался поисковыми системами, я бы не потратил вчера половину рабочего дня, а клиент денег за 4 человеко-часа. Большое тебе спасибо, дорогой 1С. Буду теперь ошибки искать отдельно в поисковике и отдельно на багборде.
Код ошибки в bugboard 50014467.
Исправлена: "Технологическая платформа", версия 8.3.19.1522
Исправлена: "Технологическая платформа", версия 8.3.20.1710
Исправлена: "Технологическая платформа", версия 8.3.21.1141 (для тестирования)
Если бы bugboard 1С нормально индексировался поисковыми системами, я бы не потратил вчера половину рабочего дня, а клиент денег за 4 человеко-часа. Большое тебе спасибо, дорогой 1С. Буду теперь ошибки искать отдельно в поисковике и отдельно на багборде.
При обновлении релиза ERP c 2.4 на 2.5 вылазит ошибка: "Ошибка SDBL: Таблица или поле Folder не содержится в разделе FROM".
Поле Folder - признак того, что запись представляет группу. Относится к справочникам. Недолго думая, настроил ТЖ для поиска на каком именно справочнике валится эта ошибка. Открыв этот справочник, вижу, что он не является иерархическим, т.е. в нем и не должно быть этого поля. Подскажите, может кто-нибудь сталкивался с такой ошибкой, куда дальше копать??
Попробовал все предложенные выше способы, даже больше (перенес базу на postgresql, попытался обновить ее там), но ничего не помогло.
Поле Folder - признак того, что запись представляет группу. Относится к справочникам. Недолго думая, настроил ТЖ для поиска на каком именно справочнике валится эта ошибка. Открыв этот справочник, вижу, что он не является иерархическим, т.е. в нем и не должно быть этого поля. Подскажите, может кто-нибудь сталкивался с такой ошибкой, куда дальше копать??
Попробовал все предложенные выше способы, даже больше (перенес базу на postgresql, попытался обновить ее там), но ничего не помогло.
Странная ситуация,
рабочая база БУХ 3.0, как только копирую файл базы или выгружаю и загружаю в новую, выдаёт:
Невосстановимая ошибка
Ошибка при выполнении запроса POST к ресурсу /e1cib/modules/call:
по причине:
Ошибка SDBL:
Таблица или поле DataSeparationUse22673 не содержится в разделе FROM
рабочая база БУХ 3.0, как только копирую файл базы или выгружаю и загружаю в новую, выдаёт:
Невосстановимая ошибка
Ошибка при выполнении запроса POST к ресурсу /e1cib/modules/call:
по причине:
Ошибка SDBL:
Таблица или поле DataSeparationUse22673 не содержится в разделе FROM
(38) Перечисленные выше советы не помогли... опытным путем установлено, что ошибка возникает при первом запуске новой базы после загрузке из .dt на платформах 8.3.20 именно из-за окна с информацией о перемещении базы.
Всегда при первом запуске загруженной базы всплывает окно с вопросом типа "База перемещена или это копия базы?".
Решение - первый запуск произвести на платформах 8.3.22, откроется это окно, в нем выбрать нужно значение и после можно снова открывать базу на прежних платформах (8.3.20).
Всегда при первом запуске загруженной базы всплывает окно с вопросом типа "База перемещена или это копия базы?".
Решение - первый запуск произвести на платформах 8.3.22, откроется это окно, в нем выбрать нужно значение и после можно снова открывать базу на прежних платформах (8.3.20).
у меня "Ошибка SDBL: Таблица или поле Fld89537 не содержится в разделе FROM" появилась после создания нового регистра сведений в расширении и добавлении его в состав плана обмена.
Вылечил удалением из состава плана обмена и добавлением снова.
Вылечил удалением из состава плана обмена и добавлением снова.
Есть клиенты, которые работают с Бухгалтерией 1.6 (файловая), в один момент стала выпадать ошибка SDBL при формировании кассовой книги, перепробовал все варианты, тестирование вылетает с ошибкой при пересчете итогов. Откатился до платформы 8.3.17.1549, кассовая книга стала формироваться, но пересчет итогов так и вылетает
Получил сегодня такую же ошибку. База серверная, поэтому бубен с "DoNotCopy" тут не поможет. Платформа 8.17 - 8.20, проверил на нескольких. Актуально. Собсно, причина как и говорилось в (40), в определении факта перемещения базы. Просматривая журнал, увидел, что падение происходит еще до тонкого клиента при запуске регл. задания "Удаление неактуальной информации синхронизации". Модуль обращается к константе "ПараметрыБлокировкиРаботыСВнешнимиРесурсами", где читает значение хранилища. Как я понял, проблема может быть в структуре этого хранилища, поэтому, при попытке прочитать несовместимые данные вываливается в трабл. ТиИ и chkdbfl результатов не дают, думаю, логика в невозможности протестировать реквизиты с типом "ХранилищеЗначения"...
Поэтому применил самое простое решение: в конфигураторе поменял тип значения константы "ПараметрыБлокировкиРаботыСВнешнимиРесурсами" на "Булево", сохранил конфигурацию с реструктуризацией и тут же, не закрывая заново поставил "ХранилищеЗначения". База открывается, данные на месте, но настоятельно советую после всего сделать ТиИ еще раз :))))
Поэтому применил самое простое решение: в конфигураторе поменял тип значения константы "ПараметрыБлокировкиРаботыСВнешнимиРесурсами" на "Булево", сохранил конфигурацию с реструктуризацией и тут же, не закрывая заново поставил "ХранилищеЗначения". База открывается, данные на месте, но настоятельно советую после всего сделать ТиИ еще раз :))))
Прикрепленные файлы:
Благодарю (46) за наводку. Добавлял реквизиты в регистр сведений через сравнить/объединить. После при попытке открыть форму записи стало выдавать ошибку
Невосстановимая ошибка
Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm:
по причине:
Ошибка SDBL:
Таблица или поле Fld56549 не содержится в разделе FROM
В тестовой базе все было хорошо. Запустил обработку ПолучитьСтруктуруХраненияИБ увидел, что новые ресурсы добавленные в конфигураторе не выводятся в списке полей. В тестовой базе они присутствуют.
Удалил добавленные ресурсы, обновился ошибка ушла. Добавил ресурсы вручную и все заработало.
Невосстановимая ошибка
Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm:
по причине:
Ошибка SDBL:
Таблица или поле Fld56549 не содержится в разделе FROM
В тестовой базе все было хорошо. Запустил обработку ПолучитьСтруктуруХраненияИБ увидел, что новые ресурсы добавленные в конфигураторе не выводятся в списке полей. В тестовой базе они присутствуют.
Удалил добавленные ресурсы, обновился ошибка ушла. Добавил ресурсы вручную и все заработало.
Была похожая ошибка при попытке обновить релиз конфигурации либо при выполнении в ТИИ реструктуризации
Ошибка SDBL: Таблица или поле DataSeparationUse6906
Использовалась платформа 8.3.18.XXXX
Помог в итоге вариант
- Поставить платформу до 8.3.17.1851, выгрузить базу в dt
- Поставить платформу 8.3.23.1997, загрузить базу из dt
- Реструктуризация прошла без ошибок, релиз обновился
Ошибка SDBL: Таблица или поле DataSeparationUse6906
Использовалась платформа 8.3.18.XXXX
Помог в итоге вариант
- Поставить платформу до 8.3.17.1851, выгрузить базу в dt
- Поставить платформу 8.3.23.1997, загрузить базу из dt
- Реструктуризация прошла без ошибок, релиз обновился
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот