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

А это ошибка в журнале регистрации....
2. Не удалось выполнить процедуру "Обновление индекса ППД":
{ОбщийМодуль.ПолнотекстовыйПоискСервер.Модуль(590)}: Ошибка при вызове метода контекста (ОбновитьИндекс)
        ПолнотекстовыйПоиск.ОбновитьИндекс(РазрешитьСлияние, Порциями);
по причине:
Ошибка SDBL:
Таблица или поле ID не содержится в разделе FROM

...
Делал выгрузку загрузку базы, тестирование .... без результатно....

когда стало известно, что 3.1.10 будут обновлять до 10.2020 решили сидеть на ней.

в 3.1.11 пока мир чудес

(1) Это я уже прочитал..... но стало поздно.

стоит подождать новой версии или откатываться назад?

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

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

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

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

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

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

(8) Платформа 8.3.13.1644

Вот что выдал при обновлении на 3.1.12

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

Имена таблиц с кодом 21: ConstChngR21, Node21
Имена таблиц с кодом 22: Const22, Node22
Имена таблиц с кодом 24: ConstChngR24, Node24
Имена таблиц с кодом 25: InfoRgChngR25, Node25
Имена таблиц с кодом 26: InfoRgChngR26, Node26
Имена таблиц с кодом 27: InfoRgChngR27, Node27
Имена таблиц с кодом 28: InfoRgChngR28, Reference28
Имена таблиц с кодом 29: InfoRgChngR29, Reference29
Имена таблиц с кодом 30: Reference30, ReferenceChngR30
Имена таблиц с кодом 31: Reference31, ReferenceChngR31
Имена таблиц с кодом 32: Reference32, ReferenceChngR32
Имена таблиц с кодом 446: Document446, InfoRgSL446
Имена таблиц с кодом 447: Document447, InfoRgOpt447
Для исправления проблемы вы можете обратиться в службу технической поддержки.

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

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

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

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

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

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

https://bugboard.v8.1c.ru/error/000051158https://bugboard.v8.1c.ru/error/000051158
Есть такая бага.
Для тех у кого нет доступа: при разворачивании из sql бекапа сбиваются номера таблиц в кластере.
Все релизы с 12 по 15 платформы до определенного релиза ее имеют. За последние 2 недели уже 2 случая когда только обновление платформы помогает

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

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

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

(19) платформа 8.3.14.1779, таки нет такой ошибки :)
А вы делали бекапы? Может того, обратно вернуться?

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

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

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

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

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

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

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

(27) sql на одном сервере с 1с.
(26) да.

1. Сделать бекап средства sql
2. ребутнуть 1с
3. восстановить бекап средствами sql

так я понял

(28) "sql на одном сервере с 1с."
И что?
См. http://catalog.mista.ru/public/1126277/
Там тема раскрыта...

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

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

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

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

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

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

(32) (33) Имхается такое подозрение, что баг не слишком зависит от версии платформы, т.е. выборы платформ между 8.3.12 ил 8.3.14 или 8.3.15 вряд ли себя проявят, но вот выборы самой конфигурации проявят наверняка.

И будет иметь значение сочетание накопившихся обновлений с реструктуризациями. В каких-то случаях создание новых баз с нуля для заливки данных из DT сможет дать работоспособный вариант на любой из актуальных платформ.

(36) Да нет, баг 100% воспроизводим, от конфигурации не зависит, см. См. http://catalog.mista.ru/public/1126277/

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

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

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

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

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

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

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

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

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

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

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

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