Уважаемые специалисты, подскажите пожалуйста, куда копать, если база данных при ТиИ выдает ошибки вида:

Объект изменен: Последовательность.ПроведениеПоРасчетамСПоставщиками
Регистрация изменена: Последовательность.ПроведениеПоРасчетамСПоставщиками

База УТ11.1, 1С 8.3.6.2237, в конфигурацию вносили изменения несколько разных программистов. При попытке запустить конструктор в консоли запросов - тот падает, в инернете пишут, что это связано с ошибками текущей конфигурации. После ТиИ вышли ошибки и конструктор продолжает падать.

(0) это не ошибки. Просто информационные сообщения

(1) спасибо за ответ, я правильно понял - эти сообщения можно игнорировать? И еще - если обработка, которая бегает по метаданным (конструктор в консоли запросов) падает - как правильно лечить базу? ТиИ не помог.

(2) может нужно смотреть обработку?

(2) при чём тут ТиИ? Оно проверяет данные, а Вам нужно проверить метаданные - конфигурацию. В конфигураторе меню Конфигуратор - Проверка конфигурации. потом можно сделать сравнение, объединение с конфигурацией поставщика в поддержке - для понимания что было изменено.

Кстати, сравнение/объединение неплохой "тест" на корректность конфигурации. Если платформа падает - конфигурация с ошибками, нет - пациент практически здоров.

Большое спасибо за советы, буду посмотреть.

И вдогонку - как правильно лечить ошибки, найденные в Конфигуратор - Проверка конфигурации? Будет ли правильным по максимуму вернуть замки на все неизменные объекты (сейчас в конфигурации сняты все замки - то есть режим "Редактируется с сохранением поддержки" -даже у нетронутых объектов.

(7) нужно было у нужных снимать

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

+(9) сам спросил - сам отвечаю - не помогают. Ошибки в проверке конфигурации - выглядят как неопасные, все у форм: Неразрешимые ссылки на объекты метаданных и Неразрешимые ссылки на типы

но увидел еще одно но - при запуске отчета по конфигурации - он падает. Методом исключения нашел редиску - план обмена "СинхронизацияДанныхЧерезУниверсальныйФормат" - на нем падает. Вернул ему замочек - падения не прекратились. Как правильно вылечить этот план (следов изменения в нем не найдено)?

В конфигураторе Конфигурация - Поддержка - Настрока поддержки, кнопка "Сравнить, объединить" - просто взять "проблемные" объекты  целиком из конфигурации поставщика.

Хотя с другой стороны, конфигурация поставщика сама тоже может быть битой :(

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

"Ошибки в проверке конфигурации - выглядят как неопасные, все у форм..." - фишка платформы в том, что конфигурация хранится совсем не так, как тебе её показывает конфигуратор. Наткнувшись на ошибку, процесс выгрузки конфигурации (для того чтобы ты с ней мог работаь) далее может нести сплошную пургу из несогласованных между собой метаданных (условно можно сказать взаимные "ссылки" слетают).

(13) Угу, выгрузить и загрузить в пустую базу, созданную для разработки без конфигурации.

Если есть архивы - можно их поочередно поднять их, каждый раз проверяя, пока не найдёшь корректный вариант. Далее его можно "подтянуть" до актуальнного состояния и загрузить в рабочую базу.

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

(14) а эти ошибки (Неразрешимые ссылки на объекты метаданных и Неразрешимые ссылки на типы) рекомендуется лечить? Или сначала надо добиться, чтобы отчет по конфигурации не падал.

(15) Спасибо за идеи, буду рыть. Кстати, могу ли я сделать такой вариант - если не удастся найти подходящего небитого объекта (план обмена) в рабочей базе и архивов - скачать типовую установку УТ и выдрать из тамошнего CF?

И еще вопрос к уважаемому гуру - я обнаружил, что объект плана обмена битый в конфигурации поставщика - как избежать подобного на будущее? Что создает такую битость - битый CF при скачивании? Ошибки 1С, ОС или железа? Кривые руки обновляльщика?

(17) "Что создает такую битость - битый CF при скачивании? Ошибки 1С, ОС или железа? Кривые руки обновляльщика?" - и то, и другое, и третье.
Были случаи выпуска типовых обновлений, после которых у многих отваливалась конфигурация поставщика;
Сбои во время обновления (например, завершение сообщением о нехватки памяти);
Работа на устаревшей для этой конфигурации версии платформы.
Ну и т.д. и т.п.

+ и моё любимое демоническое обновление :))

(16) Лечить. Если конфигурация без изменений - можно взять, докуда руки дотянутся, типовой CF из любой другой базы на поддержке той-же версии. Ну или более ранней и подтянуть обновлениями самостоятельно.

(18) спасибо за подробное объяснение, а какие способы не нарваться на кривое обновление существуют? Ну кроме не обновляться в день выхода и мониторить мисту?

(19) почему фирма 1С его (динамическое обновление) не отключит, раз оно такое опасное? Ни одна хотелка не стоит поломки базы.

И последний вопрос по теме - а как правильно заместить неизмененый объект, если есть его целая копия в отдельном CF? Если делать объединение конфигурации - то этот объект в рабочей конфигурации совпадает по содержимому с внешним CF.

(21) "Кривые" обновления от поставщиков - явление редкое (раз в год не чаще :) Чаще всего они становятся таковыми из-за вовремя не выявленных и устраненных скрытых проблем в конфигурации и в данных базы.

Защита от глюков стандартная, описанная в рекомендациях методистов 1С. Архив перед обновлением, ТиИ перед обновлением, ТиИ после обновления. "Все эксперименты на кошках, тьфу - на копия."(цы)

Динамическое обновление, само по себе, не опасное. Опасным его делает спешка программиста и юзверы, которые не спешат перезапускать сеансы и не позволяют платформе корректно совершить/завершить динамическое обновление.