Дописаная на базе БП 3.0. Клиент-сервер.
До обновления платформы. Теперь в момент проведения вот такая ошибка во всех базах. Все базы с одинаковой конфигурацией.
"ошибка SDBL таблица или поле DimHash не содержится в разделе FROM"
Стал пробовать запускать базЫ на старых движках, то же самое.
Не пойму в чем дело. Кэш, в т.ч. и кэш сервера чистил.
Получается, что в самой конфигурации ошибки нет, т.к. до обновления платформы все работало. Но ведь и на старых движках такая же ошибка.

Косяк в тексте запроса

https://infostart.ru/1c/articles/1364365/

Но вчера, до обновления платформы все было нормально.
Да и на старых релизах платформы теперь такая же ошибка.
И даже бэкап месячной давности на всех релизах платформы (старые релизы не удалялись) выдает эту же ошибку.

(3) какие релизы не удалялись?
у тебя там куча одновременно версий сервера 1С разных версий платформы поднято?

не удалялись релизы платформ. Этим только админы занимаются.

"у тебя там куча одновременно версий сервера 1С разных версий платформы поднято?"
А как это повлияет если запуск то автоматически с самой новой ?

Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm
по причине:
Ошибка SDBL:
Таблица или поле DimHash не содержится в разделе FROM

Это полный текст ошибки.
ТиИ делал, выгрузку/загрузку DT. Не помогло.

https://infostart.ru/1c/articles/1866438/

субд не меняли?

(9) Нет.

(0) с какой на какую платформу обновили хоть? Какой режим совместимости в конфе?

(11) с 8.3.23.2040 на 8.3.24.1586
режим совместимости Версия 8.3.21

Но я не пойму почему теперь и на 8.3.23.2040 не работает хотя вчера, перед обновлением работало.

(13) потому, что новая платформа сделала реструктуризацию. Откати на 8.3.21, к примеру, не будет ошибки

(0) DimHash поле в индексах регистра накоплений. Попробуй перестроить индексы.

(15) не поможет, с 98% вероятности, он же с dt загружал ужо

в (3)
это уже совсем странно

может они этот бэкап сначала на новой платформе пробуют а не сразу на старой?

(0) Ищи РН где больше 5 измерений и не у одного не стоит "Индексировать" , установи у первого. Должно взлететь.

(16) (17) Платформа обновлялась вчера (22 июля). Нашел bak от 20 июля. Запустил на предыдущей платформе . Все равно ошибка.

(19) Дай свой bak на поглядеть

Ну или для начала, поотключай все расширения (если оне есть)

(20) Не получится. Там отраслевая и валится специализированный документ. Без СЛК не будет проводиться.
Расширения поотключал, не помогло.

(22) тогда смотри, что толкает твой док. У тебя сейчас рассогласование схемы с данными. Профайлером или тж поймай, на какой табличке валится ошибка и тупо добавь поле ручками, это если не заниматься подбором верного релиза платформы, на котором не будет ошибки.

И че там такого в бп отраслевого?..чье решение хоть? Там обычно, примитив с слк, только избранные д..бы в саму длл выносят методы. Обычно, сам слк легко убирается

Бух.строй. организации Импульс Ивс.

(25) можешь на копии, понизить режим совместимости до 18, например. И поглядеть, после реструктуризации (только расширения нужно поотключать)

точно причина в обновлении платформы?
судя по описанию "Дело было не в бобине"

В общем, закинул одну из баз на свой комп, у меня платформа последняя, 8.3.25.1336.
Заремил код, чтобы можно было провести без СЛК.
Та же самая ошибка. Причем база теперь файловая.

(27) Не понятно. Документы проводились нормально. Кроме обновления платформы больше ничего не делалось.
Ну и СЛК обновили.

Расширений нет?

(30) Есть, но я все отключил

(28) см (26).

Дали еще один бэкап месячной давности.
Запустил на платформе тоже месячной давности, т.е. на той, на которой все стабильно работало.
Все равно та же самая ошибка.
Грешу на сбой самого ключа защиты БСО. Могли таблицы какие-то зашить в ключ ?

(32) До 18 не получилось, не запустилась база. Понижал до 19, та же ошибка.

(34) дай bak поглядеть

(33) Теоретически могли в защиту встроить такой механизм
Что в отраслевке изначально есть кривой регистр, но запросы/записи с ключем по нему делают специальным образом, избегая ошибки
А без ключа иным (обычным) и цепляет баг

(33) что-то мешает загрузить типовой cf БП & проверить ?

(37) Все обычные, не спец. документы нормально проводятся.
И даже остальные спец. документы нормально.
Ошибка только в одном спец. документе.

(38) ну и смотри, какие регистры он толкает. Или (20)

(38) [Ошибка только в одном спец. документе.]
что-то мешает закомментировать обработку проведения и локализовать битый регистр ?

БСО?

(30) Каюсь. Я у расширений просто снимал галку активности.
Сейчас вообще удалил и все заработало.
Но странно, почему почти месяц все работало с этим расширением.

(42) снятие галки активности расширений просто отключает их код
а добавленные/измененные метаданные в таблицах СУБД остаются использоваться из таблиц расширений
и только после удаления расширения (в монопольном режиме) копии таблиц созданные расширениями удаляются, данные переносятся (возвращаются) в основные таблицы

+43 попутно теряются все даннные, которые были добавлены в расширении (если были новые метаданные в них)

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

Нашел битый регистр.
Удалил ресурс, сохранил, вернул ресурс, сохранил.
Не помогло.
Снял галку регистратора, при сохранении та же ошибка-
Поле DimHash не содержится в разделе FROM
и не дает сохранить.
Пробовал на файловой базе и на sql.

Выгрузи все данные из битого регистра (встроенная обработка в помощь или свою наваять) в файл
Удали этот регистр
Создай заново
Проверь проведение доков
Загрузи данные

(47) при наличии серверной базы, это самый медленный и не оптимальный способ.

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

(48) Я тоже так думал. Удалять таблицы скриптом ?
Но выше написал, что даже при пустом регистре, все равно ошибка.

(50) для данной задачи, удалять вообще ничего не надо.

DimHash

Составной тип вот и проблемы

(51) А как ?

(54) ms sql? Регистр хоть какой? Бух, останки, обороты, рс ?

Остатки, ВыпускПродукцииУслуг
Что интересно, в него записи не ведутся вообще.
Да, ms sql

(56) откуда это известно, если ты его прибил?

И, если б туда ничего не писалось, док бы проводился

(57) Я же на копии делал, а в оригинале смотрел.
(58) Пустой этот регистр. Он же для плановых цен.

(59) с чего тогда уверенность, что это он ошибку выдает?

(58) Оно вероятно падает на запросе к нему
А не при записи

(60) Отладчиком наткнулся. Потом вообще удалил, восстановил, убрал регистратор и теперь все нормально работает.

Кстати вангую:
  

Скоро подобных тем будет все больше!

Ибо в 1С начали забивать болт на MSSQL, пользуют и тестят только PostgreSQL
Сам недавно столкнулся с подобной траблой, что типовая конфа на PgSQL пашет а в MSSQL нет, даже не грузится из dt
А если каким то хитрым местом загрузить - ТиИ не проходит и обработчики обновлений типовые падают

(63) "Ибо в 1С начали забивать болт на MSSQL, пользуют и тестят только PostgreSQL"
Соседи, тоже с БСО, но только на PostgreSQL и такая же ошибка.
Да и на файловой базе то же самое.

(62) И в каком коде ошибка ? В запросе ?

(65) Нет, в Движения.Записать()
Дальше идет куча проверок. Так вот если исключить этот регистр из записи, то ошибки нет

У меня таких штук 10 баз. Подготовил cf где нет регистра.
Загружаю, сохраняю. В этом случае не ругается, что "Поле DimHash не содержится в разделе FROM" . Тут же загружаю исходный cf, только снимаю галку движения по этому регистру у проблемного документа.

Так кривое то расширение или сама конфа?

(68) Расширение. Конфигурация то в этой части полностью "заводская".
Если расширение удалить, то вообще никаких манипуляций с регистром делать не нужно.
Но т.к. в расширении метаданные, то пришлось вот таким способом исправлять. А позже разработчик расширения разберется и исправит.

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

(70) покажи структуру таблиц БД по проблемному регистру обработкой из 1С

(71) там типовой ВыпускПродукцииУслуг, есть в любой БП.

(72) в расширение РН ВыпускПродукцииУслуг добавлен? Какой установлен уровень совместимости БД в SQL и какая версия SQL?

(72) Да, типовой в метаданных, но раз у тебя валится, то структура БД отличается

(73) Нет, не добавлен.
SQL ни при чем, я же загружал в файловую, та же ошибка.

(75) думаешь кривая структура БД при выгрузки/загрузки в файловую починится? Не обязательно. А кривая стала из-за чего? Какие-то индивидуальные версии приложений/последовательности действий к этому привели.

В общем, можно топорно у РН ВыпускПродукцииУслуг у одного из измерений убрать составной тип, тогда надобность в поле dimhash не будет, оно удалится. Проверить на ошибку, добавить составной тип заново, проверить, если индивидуальные условия уже не те что были при появлении ошибки, значит всё.

(76) Там все осложняется что расширением сделали кривым

(77) можно в ТиИ сделать реструктуризацию таблиц расширений, это отдельный пункт, возможно и пропустить

(76) Я не думаю, я знаю, что не починится. Выше писал, что не прокатило.
А составных типов в измерениях нет.
(78) Реструктуризация проходит только если предварительно удалить регистр, сохранить базу, вернуть регистр и после этого запускать рестр-ю.

(79)
Да, но я уже хз сколько там не работаю

(79) ну как нет-то, субконто с типом характеристики,а ПВХ составные

(81) Помогла реструктуризация расширения. Предварительно в одном из измерений включили индексацию.
Я не допер, это коллега разобрался.

УХ
Платформа 8.3.25.1286
Поймал точно такую же ошибку, тот же самый регистр ВыпускПродукцииУслуг

Иду по сообщениям из ветки, пока решения не нашёл.

(83) Там другой регистр.

Выпуск услуг... :)

нотариально заверенный пруф https://radikal.host/i/snimok.gYhr9r

(86) В сабже другой регистр

(83) расширения уже отключил и УДАЛИЛ?

(87) понял, спасибо.
(88) да, пробовал отключить и удалить - не помогло.

(89) И ТиИ после сделал?

(88) Простите великодушно, не очень знаю расширения. Отключить и удалить расширение — это разные действия?

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

(92) Спасибо, что пояснили. А то я уж подумал, что мне плохо...