Таблица или поле configversion не содержится в разделе from 1с
Обновлено: 04.07.2024
Для начала, сразу скажу, что ТИИ базы со всеми галками до обновления сделано, ошибок не выдает.
Конфа БП 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-х (ниже), точно такая же картина с одним предопределенным элементом.
Только вот сейчас ответили "Ваше письмо будет рассмотрено в ближайшее время".
(15) ну вот, тот что помечен на удаление, удалите нахрен. Бывших узлов не бывает.
(18) Его невозможно удалить, на него куча ссылок, т.к. раньше до EnterpriseData этот обмен использовался.
Да и я думаю он никак не влияет, какой-то косяк с планом обмена Полный, а не с ним.
(19) Поздравляю!
А мне даже еще не ответили в какую сторону хотя бы копать.
(20) вот именно он и влияет. Так что тянуть с удалением нет смысла.
Обновил в выходные типовую рабочая базу. Без проблем обновилась и работает на рекомендованной платформе 8.3.12.1529 (правда в базе не используются синхронизации)
(23) У пользователей с ограниченными правами при поиске в динамическом списке (например в документах реализации) ошибок не возникает?
В (3) этот ответ прозвучал. Я на платформе 8.3.12.1685 обновился успешно, только долго адски
(21) У меня при запуске самописки на 8.3.12 в планах обмена самопроизвольно очистились значения реквизита "ЭтотУзел" у всех узлов всех планов обмена, и тоже посыпались ошибки. После "ручной" установки значений все заработало. Проверь на всякий случай.
(25) Пробовал на платформах 8.3.12.1595, 8.3.12.1685, 8.3.13.1513 -- результат одинаковый как в (0)
Попробовал выгрузить базу в dt-файл и загрузить обратно. Не помогло.
(26) А как это сделать?
После наката обновления по F7 и старта базы как-то можно отказаться от запуска обновления в предприятии?
(0) Попробуй запустить тестирование(без исправления) с 4я первыми галками сразу после завершения обновления в конфигураторе, была такая беда с типовой - помогло.
(26) В окне "Не удалось выполнить обновление" есть кнопка Еще - Открыть внешнюю обработку.
Запустил внешнюю обработку с таким кодом:
Выдает "Да".
Т.е. значение реквизита не слетело.
(31) я бы и остальные планы обмена так проверил, не только полный. Ведь в (0) явно ошибка в каком-то узле обмена. В крайнем случае попробовать на копии удалить все узлы обмена с отключенным контролем целостности и попробовать обновиться.
Т.е. до обновления ТИИ проходит без ошибок, после обновления в конфигураторе -- база поломанная. Релиз платформы последний. Фирма 1С молчит как партизан.
Таблица была "dbo._AccRgAT2486", SQL ругался на неуникальность конкретного индекса. В Management Studio я временно разрешил этому конкретного индекса пропускать повторяющиеся значения,а после выполнения всех процедур обратно запретил.
Но что за таблица "dbo._tmpRCT"?
(35) При ТИИ создается такая таблица в скулевской базе:
0x0000001B -- строка с таким значением есть.
Хз почему пытается вставить в эту таблицу еще одно такое значение. Естественно, скуль не даёт это сделать.
При ТИИ базы до обновления в таблице _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 и меняется режим совместимости.
Но так пока что и не ясно как починить базу до обновления, чтобы изменение режима совместимости при накатывании следующего релиза не ломало базу.
первое решается путем расследования тж либо трасс ms sql profiler на предмет , откуда 1с8 берет данные для таблицы с последующим исправлением.
второе - отключением индекса при создании таблицы, удаления дублей, создание индекса.
Выяснил, что планы обмена изменяются при включении режима совместимости 8.3.11.
Т.е. если включить возможность изменений и просто изменить режим совместимости конфигурации с 8.3.10 на 8.3.11 то баг с ТИИ воспроизводится.
При откате обратно на 8.3.10 бага при ТИИ нет.
Методом последовательного удаления планов обмена из конфигурации выяснил, при снятии с поддержки и удалении только 1 плана обмена УдалитьОбменРозницаБухгалтерия20 баг с ТИИ пропадает.
Т.е. после последующего обновления без этого плана обмена до версии 3.0.65.69 ТИИ базы проходит успешно.
Но проблема обновления в предприятии, описанная в (0), всё еще остается.
(33) >В крайнем случае попробовать на копии удалить все узлы обмена с отключенным контролем целостности и попробовать обновиться.
Удалил обработкой все непредопределенные элементы всех планов обмена (у которых свойство ЭтотУзел = Ложь) перед обновлением.
Та же ошибка после обновления при обработке данных в предприятии.
(36) >как вариант попробуй в файловый вариант сконвертить и там обновить
На файловой базе та же ошибка.
ТИИ и chdbfl и до, и после(!) обновления рапортуют, что проблем нет.
При этом, если при появлении ошибки обновления в предприятии открыть обработкой элемент плана обмена Полный и попробовать записать -- вываливается в ошибку SDBL.
Ответ поддержки 1С, цитата:
Что надо сделать?
P.S. Я им отправлял .bak-файл MSSQL-бэкапа текущей базы до обновления.
Напомнил им сегодня о себе.
Посмотрим на следующей неделе что ответят.
Писец. Просто нет слов.
То есть по факту слить базу. На такое никто в здравом уме разрешения не даст.
(51) А вариант создать пустую базу из шаблона конфигурации и перелить туда все данные через выгрузку-загрузку через XML не рассматривали ? И на новой базе уже проводить обновление.
(55)[То есть по факту слить базу. На такое никто в здравом уме разрешения не даст.]
ты бредишь и тяжело, не запуская болезнь
(57) Если ты один айтишник который обслуживает организацию и о твоей идее слить базу куда-то (пусть и с целью починить) никто не узнает то можешь делать что угодно.
Я при приеме на работу подписывал бумаги за сохранность коммерческой тайны. И без письменного разрешения начальника отдела ИТ сливать базу куда-то рискуя уголовкой не собираюсь. И начальник отдела тоже в таком случае захочет прикрыть свой зад бумажкой.
В общем, исправления бага я так и не дождался, решил проблему обновления в предприятии правкой кода:
И благополучно обновился до последнего релиза.
ТИИ с исправлением ссылок так и не запускается с ошибкой PRIMARY KEY, но, я думаю, что это ошибка в платформе и когда-нибудь она сама пропадет.
У этой истории неожиданно появилось продолжение.
При попытке загрузки данных из УТ:
Никогда таким не занимался, чтобы перенести все данные из базы в пустую базу.
Подскажите, как это сделать?
столкнулся с похожей ошибкой при обновлении УТ11. Помог откат на 8.3.10, ТИИ (вроде можно только реструктуризацию, но сделал полностью) и обновление на этой платформе
(61) Создаете пустую базу из шаблона релиза такого же что и ваша база. Если такого шаблона нет то берете ближайший до этого шаблон и накатываете на него обновления пока не получите базу того же релиза. Если у вас есть изменения в метаданных (как у меня например в справочник контрагентов и договоров добавлены несколько реквизитов) то включаете возможность изменения и добавляете.
Обязательное условие - конфигурация по метаданным должна совпадать. Иначе выгрузка - загрузка через XML не пройдет.
После этого обработкой ВыгрузкаЗагрузкаДанныхXML выгружаете все данные из баз источника. Я делаю "все контатанты, все справочники, все документы с движениями". Плюс надо будет дополнительно перенести независимые регистры сведений (по которым движения без регистраторов).
Если во время выгрузки будет происходить ошибка на каких то объектах то просто снимаете галочку на объектах этого вида.
(60) (62)
Какую у вас ошибку выдавало ТИИ с реструктуризацией ?
"В процессе обновления информационной базы произошла критическая ошибка
по причине:
В схеме базы данных отсутствует таблица "Reference39".
В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка SDBL:
По структуре БД я определил что Reference39 это Справочник.ДолжностиОрганизаций.
Соответственно выгрузка этого справочника через XML тоже падала и приходилось ее пропускать.
После отката на релиз 8.3.10 эти ошибки ТИИ при реструктуризации ушли ?
Ошибка SDBL:
Ссылка на таблицу недопустима. Нет таблицы или отсутствует RefSelf.
Но ругалось вроде на перечисление. На 8.3.10 прошло без ошибок
(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 под которым можно провести обновление без ошибок в реструктуризации ?
Реально помогает до какого-то момента.
(65) Вообще конечно подход 1С что под релизом 8.3.10.2561 ТИИ проходит без ошибок, а под релизом 8.3.13.1513 ТИИ заканчивается ошибкой удивляет.
Данные же одни и те же.
(65) Попробовал на релизе 8.3.12.1685 который рекомендуется для обновления.
При обновлении в процессе реструктуризации выдает ошибку
"В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка SDBL:
по причине:
Ошибка SDBL:
При этом под релизом 8.3.10.2561 ТИИ проходит без ошибок.
"Приаттаченная база 3.0.64.54 уже содержит проблему, но внешне она не проявлялась. Проблема в том, что в базе 2-е таблицы Const24 и Node24 с одинаковым постфиксом."
(70) Вам проблему с базой удалось решить ?
Я у себя решил проблему созданием новой базы из шаблона и переливанием в базу данных.
(71) В общем, поддержка исправила отосланную базу, но инструмент по исправлению (или хотя бы инструкцию) давать отказалась.
Цитирую:
"Восстановить базу пользователь самостоятельно не может, т.к. нужно обновлять также служебные структуры. Мы можем восстановить конкретную проблему, при этом, повторюсь, мы не можем гарантировать что других проблем не будет."
С учетом того, что они решали проблему 3 месяца, база, которую я им отсылал, стала неактуальной и мне уже нафиг не нужна, тем более, что это не гарантия, что в дальнейшем проблем с ней не будет.
Я решил проблему взятием бэкапа полугодовой давности, в котором точно всё хорошо, и перезаливом данных за полгода из УТ.
Да, возможно бухам придется заново что-то руками подправлять в базе, но это лучше, чем подобный баг вылезет в дальнейшем в исправленной каким-то неведомым способом базе.
Кстати, у меня не взлетели автосгенерированные правила конвертации БП => БП. Справочники еще норм переносило, а на документах вываливалось в ошибку
Не подскажите на будущее как правильно эти правила создавать в конвертации 2.0 или может быть какая-то особенная обработка нужна?
Почему возникает ошибка
Рассматривая нами ошибка SDBL является представительницей целого пула схожих ошибок с текстом « Таблица или поле не содержится в разделе FROM ». Такие ошибки обычно связаны с повреждением базы данных из-за различных причин, самой распространённой из которых является технический сбой в работе системы 1С.
Среди других причин ошибки SDBL также выделяют:
- Использование устаревшей конфигурации или платформы 1С;
- Проблемы с кешом сервера 1С;
- Запуск системы с недостаточными правами (к примеру, от имени учётной записи гостя вместо администратора) и другие причины.
Ошибка возникает при попытке обновления базы данных, добавления документа в базу данных, при тестировании базы данных на логическую целостность и других схожих случаях. При этом перезагрузка системы обычно никак не решает возникшую проблему.
Убедитесь в наличии достаточных прав для запуска системы
Первым делом убедитесь, что вы запускаете вашу систему с правами администратора. Недостаточный уровень прав может приводить к появлению различных проблем при работе с 1С.
Обновите вашу конфигурацию (платформу) 1С
Также проверьте, пользуетесь ли вы самой свежей версией платформы (конфигурации) 1С. При необходимости обновите вашу систему до самой свежей версии продукта. Это может помочь устранить ошибку SDBL с полем configversion в 1С.
Используйте инструмент «Тестирование и исправление».
Данный инструмент запускается переходом в конфигуратор, где в разделе «Администрирование» нужно выбрать опцию «Тестирование и исправление». Дождитесь окончания процедуры, после чего проблема может быть решена.
Выгрузите и загрузите файл Dt
Хорошие результаты в избавление от ошибки «поле configversion не содержится в разделе FROM» показал способ, состоящий в выгрузке и последующей загрузке файла Dt (архивной копии базы 1С). Для выгрузки базы зайдите в Конфигуратор, там выберите «Администрирование» , где нажмите на «Выгрузить информационную базу».
Перезагрузите сервер 1С
Для устранения дисфункции рекомендуем перезагрузить сервер 1С. Перезагрузка указанного сервера обычно выполняется автоматически на протяжении 3-5 минут при условии отсутствия у сервера подключенных пользователей.
Очистите кэш сервера 1С
Туда нужно перейти и удалить папки с генерированными именами. Учтите, что кроме кэша в данной папке могут находиться журналы регистрации, а также индекс полнотекстового поиска 1С.
Очистите таблицы в менеджере SQL
Также можно попробовать выполнить очистку таблиц таблицы _ConfigChngR и _ConfigChngR_ExtProps с помощью команды delete.
Заключение
Нередко пользователи платформы 1С сталкиваются с ошибкой SDBL. Она может иметь различный характер, все зависит от конкретной надписи. Наиболее распространенный вариант — это ошибка: SDBL таблица или поле configversion не содержится в разделе FORM. Мы постараемся не лезть в дебри, а рассмотреть наиболее эффективные и общие способы решения данной проблемы.
Причины ошибки SDBL
Как писалось ранее причин, по которым появляется данная ошибка, может быть достаточно много. Обычный пользователь вряд ли самостоятельно сможет идентифицировать, в чем же именно кроется проблема. Однако, как правило, ошибка SDBL возникает во время обновления или установки конфигураций или в момент реструктуризации базы данных. В целом, можно заключить, что в 90% случаев данная ошибка показывает, что имеется некий технический баг в базе данных платформы 1С.
Независимо от того возникают у вас ошибки или нет, рекомендуем регулярно делать резервное копирование данных базы 1С. Это спасет ваши ценные данные в случае аварийной ситуации. Резервное копирование делается достаточно просто. Для этого войдите в «Конфигуратор», после чего нажмите на вкладку «Администрирование» — «Выгрузить информационную базу».
Создание резервной копии
В случае необходимости для загрузки сохраненной копии нажмите на пункт «Загрузить информационную базу».
Как решить проблему
Итак, если вы решили самостоятельно попробовать решить проблему, то необходимо попробовать следующее:
- Перезагрузить сервер 1C и сервер SQL. Инструкций как это делается в интернете достаточно много, поэтому не будем на этом заострять внимания. Конечно, этот способ вряд ли сможет вам помочь, но стоит попробовать.
- Отчистите кэш в сервере 1C. Для этого необходимо перейти в папку, где хранятся временные файлы 1С. Данный адрес можно посмотреть в настройках клиента. Далее необходимо перейти в папку «Local» — «1C» — «1Cv82». Папки с длинными и непонятными наименованиями и есть тот самый кэш, его можно смело удалять.
В этой инструкции мы специально не писали способы, в которых необходимо исправлять программный код и т.д. Это подойдет только для продвинутых пользователей или системных администраторов. В любом случае, если ничего из вышеизложенного вам не помогло, то лучше обратитесь в техподдержку или вызовите специалиста на дом или в офис компании.
Итог
Нередко случается ситуация, когда во время работы в программе 1С Бухгалтерия внезапно появляется окно с текстом: «ошибка /e1cib/modules/call», после чего программа экстренно закрывается. Сегодня мы поговорим о причинах этой проблемы и рассмотрим способы ее решения.
Причины ошибки e1cib modules call
Примерный вид ошибки
Однако, как было замечено, чаще всего ошибка появляется при обновлении на новые конфигурации программы: 8.3.6, 8.3.8.хх, 8.3.9.xxx. Как говорилось ранее, причина сбоя e1cib modules call наверняка кроется в программном коде самого софта, поэтому причина кроется не в настройках компьютера. Сфокусируем внимание на решении проблемы по описанной далее инструкции.
Способы решения ошибки e1cib modules call
Чтобы решить ошибку /e1cib/modules/call попробуйте проделать следующее:
1. Первое, что необходимо сделать, это выполнить стандартную процедуру проверки и правки клиента. Для этого необходимо зайти в конфигуратор, перейти в раздел «Администрирование» — «Тестирование и исправление». Стоит помнить, что данную процедуру необходимо выполнять в монопольном режиме, т.е. кроме вас в конфигураторе настроек не должно быть других пользователей. Также перед выполнением данной процедуры рекомендуем выполнить резервную копию данных.
Тестирование и исправление
3. Если вышеуказанные способы вам не помогли, попробуйте откатить программу на предыдущую версию. После чего, сперва обновите платформу, сконвертируйте ИБ и только после этого обновляйте конфигуратор БП на новую версию.
4. Многие специалисты рекомендуют почистить кэш для корректного подключения к серверам. Для этого удалите в папке кэша все файлы, исключая те, которые имеют расширение *.1. Обычно каталог находится по следующему адресу: Program Files/1cv8/srvinfo/reg_1541.
5. Попробуйте перезапустить сам сервер 1С. Часто это помогает решить проблему.
6. В конце концов, свяжитесь с техподдержкой. Специалисты поддержки наверняка порекомендуют актуальный способ решения проблемы и обновления компонентов.
Итог
Как вы уже поняли ошибка «ошибка /e1cib/modules/call» затрагивает пользователей глобально и чаще всего возникает после обновления клиента 1С на более новую версию. Выполнив все вышеуказанные действия, ошибка с большой вероятностью исчезнет. Если у вас остались вопросы или вы знаете более эффективный способ решения проблемы, то напишите его в комментариях.
Читайте также: