Доброго времени суток.
Столкнулся с очень странным поведением РИБ.
Заметил, что обработка проведения в одном из документов в центральной базе и в периферийной отличаются (в центральной "рег.Продукция= стр.Пачка.Номенклатура;", в периферийной - "рег.Продукция= стр.Номенклатура;"), хотя обмен успешно идет (но конфиурации, получается, не идентичные).
Что делал:
1. Выгружал конфигурацию периферийной, делал "Сравнение, объединение" на основной - отличий не найдено.
2. Делал в центральной изменения в другом документе, обновлял периферийную - обновления другого документа применяются, обмен идёт без проблем, изменения в обработку проведения "проблемного" документа не поступают
3. Добавлял новый документ в конфигурацию центральной, обновлял периферийную - новый документ в периферийной присутствует, обмен идёт без проблем, изменения в обработку проведения "проблемного" документа не поступают
4. Выгружал копию рабочей базы (*.bak, обе базы - SQL) на другой компьютер, делал "Сравнение, объединение" с конфигурационным файлом периферйной - отличий не найдено.
5. Снимал признак РИБ у периферийной базы, делал "Загрузить конфигурацию из файла" - обмен идёт без проблем, изменения в обработку проведения "проблемного" документа не поступают.
Единственное что я не делал - это собственно не вносил изменения в обработку проведения "проблемного" документа, т.к. тогда "парадокс" может пропасть, а я боюсь что такие вещи могут сейчас происходить и с другими объектами в конфигурации.
Прошу помощи у знающих людей - что это может быть, и что ещё стоит попробовать.
Обмен сейчас настроен через электронную почту по причине временной неработоспособности FTP сервера.

Забыл уточнить - конфигурация «управление торговым предприятием для Украины 1.2», версия платформы - 8.3.8.1652

А если проблемную базу из бакапа развернуть на новое место, вот на совсем новое и перепровести проблемный документ : изменится результат проведения?

(0) расшифруйте вот это :

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

Это код модуля проведения разный или сами данные в ИБ ?

(3) именно код модуля объекта документа

(2) развернул bak-файл на домашнем компьютере - конфигурация соответствует периферийной. Делаю "Сравнение, объединение" с конфигурацией центральной базы - соответствуют.

(5) *развернул bak-файл копии периферийной базы РИБ.

(4) не верю. Если сделал загрузить измененную в ПБ, отвязанной от центра, то там конфа полностью заменяется целиком и станет равной центру один в один.

Выгрузи конфу из центра в cf, отвяжи ПБ от главного узла, сделай загрузить измененную, сохрани, установи главный узел. Усё

(7) вот что меня очень сильно удивило, так это то, что этот метод не помог. Писал об этом в пункте 5.

(7) Sorry, но это общераспространённое заблуждение :( Загрузка из CF позволяет заменить конфигурацию поставщика и основную. Изменение же конфигурация БД происходит по "обычной" методике сравнения и объединения и не даёт 100% гарантию ликвидации ошибок демонического обновления.

Имхо: нужно внести любое изменение именно в то место конфигурации, где выявлено расхождение (в тот-же самый модуль, в ту-же самую процедуру/функцию). После устранения расхождения изменение можно "откатить".

(10) нет. Конфа БД перезаписывается из текущей.

(12) Нет, не "перезаписывается" - сравнивается (например, сравнением версий) и объединяется (например, заменой измененных) объектов метаданных (модули/функции/процедуры в т.ч.). Не важно как именно изменялась основная конфигурация (обновление/объединение/загрузка) - а конфигурация БД обновляется по своей единой методике сравнения и объединения.

(13) не придумывай ерунды

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

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

(15) кэши чистил?

(15) Попробуйте выгрузить конфигурацию БД в файл и сравнить её с основной - сравнение в таком случае происходит несколько по другой методике.

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

Я задавал выше вопрос о перемещении базы на новое место, чтоб оторвать ее от прежнего кэша, если не удалять его вручную физически - сделал?

(17) Нет, попробую вечером, когда база будет не так нагружена

(20) Так на копии из архива подними и проверь. Не трогай боевую раньше времени. Убедись просто - это кэш или что-то иное.

(13) Конфа полностью заменяется без всяких сравнений. Проверить жешь элементарно

Поэтому..многие при загрузить измененную,в момент реструктуризации долго удивляются..куда енто данные проипались, ведь я же документ одинаково назвал..

(22) Я говорю не про конфигурацию поставщика и основную, а про конфигурацию БД.

(24) она полностью заменяется, без всяких сравнений. У нас вообще конфа поставщика вырезана сто лет в обед

Возьми cf от зупа и сделай загрузить измененную в БП  и ты всё поймешь сам.

(25) Алё, гараж! При чём тут конфигурация поставщика. Может быть вы говорите о том, как в подчиненном узле происходит обновление конфигурации БД (изменения принимаются без их анализа). А автор говорил, что "отвязывал" и загружал конфигурацию - это уже автономная БД и правила обновления конфигурации БД - другие.

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

(27) Да, у нас конфигурация сильно измененная (не на поддержке), за 4 года на моей памяти таких проблем с периферийной базой не было.

(27) дык читай своё (24)

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

При загрузить измененную, никаких "правила обновления" нет и не было. Тупо конфа ИБ заменяется целиком и всё.

(30) Сами прочите своё "Конфа полностью заменяется без всяких сравнений." - о какой конфигурации Вы речь вели? Их там три :) Две из них меня совсем не интересуют. В РИБ-базе их ещё больше :) Но меня интересует только одно: как сделать конфигурации БД идентичными.

(21) (32) да - и "Загрузить конфигурацию из файла" файла cf центральной базы делал после очистки кэша на домашнем компе, всё равно код процедуры проведения выглядит как он сейчас есть в периферийной.

(34) не верю.
)

база на sql ? если да, то сделай для перефирийки truncate table dbo.ConfigSave ;truncate table dbo.ConfigCAS;truncate table dbo.ConfigCASSave, отвяжи от центра и сделай  загрузить измененную с cf от центра обнови, затем назначь главный узел

(33) При получении изменений в РИБ - нет там ни сравнений, ни объединений. Получил? Ошибки сверены по хешам? Нет ошибок - записывает. Есть ошибка - не записывает. Все.

Из РИБ (при получении данных) записываются объекты целиком в Текущую. На завершении обмена выдается предупреждение, что текущая БД изменена.
Надо входить в конфигуратор и применить полученные изменения к конфигурации БД.

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

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

(37) Я говорил и говорю про конфигурацию БД центральной базы, о принципам обновления/изменения конфигурации автономной базы. Ок? Когда речь идёт о "Загрузить конфигурацию из файла" - можно забыть про РИБ. Так понятно?

(36) Да, SQL.
При выполнении запроса в Management Studio выдает ошибку:
"Сообщение 4701, уровень 16, состояние 1, строка 2
Не удалось найти объект "ConfigCAS", так как он не существует, или отсутствуют разрешения."
Подскажи пожалуйста что сделать, я в этих вопросах не силен.

(37) :[ контрольный выстрел :]
Загружаю конфигурацию из файла CF... Вопрос: "Выполнена полная загрузка конфигурации. Обновить конфигурацию базы данных?" - "обновить", а не "загрузить"! Впрочем, как говорил Карлсон, - это мелочи жизни. После паузы... если есть изменения в объектах метаданных... та-дам! - окно "Реорганизация информации" с надписью: "Изменения в структуре информации конфигурации" и далее в таблице "Объект изменен..." Monsieur, que se passe-t-il? Sur quoi il s'agissait? Значит всё-таки не "грузится", а сравнивается и объединяется (если есть таблица изменений) ?

В подчинённом узле РИБ, имхо, всё тоже самое, но: без вопросов пользователю, принимаются все изменения. Изменения, сэр :)

PS: обычно демоническое обновление прячется в кэшах, но в сложных случаях, оно уже проникло и сидит в самой конфигурации. Имхо, разумеется.

(36) У меня из похожих таблиц есть только dbo.Config, dbo.ConfigSave, dbo.DBSchema

(42) ошибочное твое мнение

(36) сделал truncate table dbo.ConfigSave (на копии периферийной на домашнем компьютере) - не помогло, всё равно при "Сравнении, объединении" показывает что нет различий.
Я думаю дело всё таки в выгрузке cf-ки из основной базы, т.к. я сейчас на чистую конфигурацию загрузил ("Загрузить конфигурацию из файла") выгрузку из основной - код не совпадает (то, что я вижу в конфигураторе основной базы и то, что я вижу в конфигураторе новой базы, которая была загружена из файла).
Сейчас попробую развернуть свежую копию основной базы на домашний комп, оттуда выгружу cf, если не поможет то сделаю truncate копии основной и ещё раз выгружу.

(45) прикольно... А если сравнивать выгруженную из основной базы с основной базой? Получается, что срабатывает некая подложка, из которой вытаскивается модуль объекта, несовпадающий с его состоянием в Текущей конфигурации Центральной БД. Соотв. оно же ( несовпадающее ) и в выгрузку изменений пишется, если вообще туда это изменение пишется.

Т.е. проблема не в состоянии переферийной базы, а в состоянии центральной :-)

(46) Интересно ещё то, что при создании новой базы на домашнем компе из bak-файла копии центральной я опять таки в коде вижу тоже самое, что и в коде рабочей периферийной.
Выгружаю cf-ник из копии рабочей на домашнем компе, делаю "Сравнение, объединение" с рабочей базой (глазами в конфигураторе вижу различия в коде обработки проведения документа) - различий не найдено.
Причём решить проблему именно с этой обработкой проведения это дело 5ти минут - внести изменения в модуль, обновить обе конфигурации. Меня больше волнует вопрос а что же вообще происходит, и есть ли подобные различия в других местах конфигураций...

(47) В центральной базе: чистим локальные кэши конфигурации. Если клиент-сервер - то и на сервере тоже.
Далее: Конфигурация - Сохранить конфигурацию в файл.
Далее: Конфигурация - Конфигурация базы данных - Сохранить конфигурацию БД в файл.
Далее: Конфигурация - Загрузить конфигурацию из файла.
Будем исходить из того, что конфигурации стали идентичными и их можно "Сравнить, объединить с конфигурацией из файла"...

(47) так это как бы объясняет, почему периферийная так принимает... Что ей дают, то и принимает.

Может это будет немного странно выглядеть в качестве рекомендации, но попробую ее все же выдать :-)
Платформа самой 1С все-таки достаточно старая. А на таких, условно старых платформах, заводил в корень конфигурации изменяемую, но нигде не нужную константу (еще пробовал значение версии конфигурации портить).
Например, константа с типом строка в несколько символов. Менял каждый раз количество символов в длине этой константы, когда хотел выгрузить через РИБ всю конфигурацию (как я ее видел в тестовой). Конфигуратор сообщал при сохранении этого изменения, что регистрационная инфа изменена и шлепал в изменения ВСЁ. Размер обменного файла становился примерно равным размеру цф-файла, если других изменений в базе не было.
Периферийка этот обменный файл заливала целиком, также как и "загрузить из файла".

На этом практическом опыте основаны мои утверждения, что в некоторых постах ветки заявлено недостоверное поведение платформы, когда якобы идут сравнения и объединения, но на практике  они не идут.

И да, при использовании РИБ категорически не приемлемы действия "сравнение и объединение" - нет в РИБ этого и не было никогда.

(43) тогда только configsave

Ну что ж... ветка уходит под замок на радостной ноте некоторых ее участников