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

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

динамически точно не делаю - знаю что это за зверь.

(0) Как вариант - не вносить изменений в конфигурацию. А если вносишь, то от этого никуда не деться.

(1) ну так каждый день в какой-то дочке слетает конфа - это же не дело

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

(4) Странно что проблема возникает только на некоторых узлах. У нас как правило если глючит - сразу все дочки.

я уже полтора года несколько раз в неделю обновляю конфу, нормально всё было

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

(8) Мистика. Дочка файловая ? - мож ушлые пользователи решили копией базу подменять

+(9) Хотя в этом случае ругалось бы на старый номер сообщения.

(9) Нее. Тогда бы всплыли другие проблемы. Например, с нумерацией сообщений обмена.

периодически не выходят пользователи ночью из базы и не дают обновить конфу?

(12) да если не выходят я их выкидываю.

С одним узлом такое получилось: никак обновления ни туда ни сюда ни грузились, писалось "конфигурация ИБ не соответствует ожидаемой". Я сделала как в http://infostart.ru/public/65456/ по второй методике. В дочку из главной загрузилось. А вот в главную из дочки нет. Так и пишет в гланой при выгрузке, что "конфигурация ИБ не соответствует ожидаемой". Как-то можно из дочки в главную выгрузить?

ох..... а если я главную базу скопирую - из неё можно сделать дочернюю?

(15) можно, я разрешаю...

в сообщении обмена из дочки заменила блок config на тпкой же из другой дочки и в главную загрузилось

(17) т.е. эти блоки в сообщений от дочек различались?

1. выгружаешь из главной конфигурацию ...
2. в дочке отключаешь главный узел
3. загружаешь ... именно загружаешь ... конфигурацию из главной в конфигурацию дочки
4. восстанавливаешь главный узел
5. проводишь штатный обмен

(19) да делала так несколько раз - не помогает

(18) да отличались

2(20) так не бывает. Это не может не помочь.

Еще раз обновить главный узел, и прогнать обновление по всей распределенке.

(22)в принципе вы правы.
Вот какую я закономерность заметила: загрузив в дочку конфу из узла я провожу обмен туда-сюда по много раз вручную - всё нормально. Но как только включаю автоматом обмен - слетает и ругается на несоответствие конфигурации опять.
Хотя это мне вообще не понятно, в чём разница-то?

Автоматическое обновление у меня настроено через ftp-сервер (на вкладке "автоматический обмен")каждые 15 минут.

транспорт не имеет значения, автоматизм/интерактивность также не имеют значения.
имеет значение только динамическое обновление.

еще момент. возможно нужно просто почистить кэш. и серверный тоже

(24) потому что там надо в конфигуратор войти и обновить конфигурацию базы данных. Это вручную лучше сделать.

+(27) ффу, точно.. даже не заметил.. (24)с чего вы взяли что это нештатный режим?

(0) Некоторые 1сники не изучают ЧаВО, это ж баян

Его выпустили!!!! Спасайтесь кто может!!!

(27) что-то мне подсказывает, что дело у ТС не в этом.
(0) как дела?

(27) UpdateDBCFG в пакетном режиме прекрасно отрабатывает. Есть 14 баз УРБД (магазины на УТшке) - не набегаешься по ним. В батнике раз в ночь запускается обмен, потом UPDATEDBCFG (даже если изменений не было) - потом опять обмен. И всё работает как часы. Если несколько пользователей работают, то необходимо завершать работу всех пользователей перед апдейтом.

Кэш чистился? Иногда начинает куски конфы оттуда брать.

(31) ничего пока не получается. Пробовала скопировать главную и сделать из неё дочку - тоже не даёт (ошибка метода контекста).

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

тут так совпало, что винду на сервере переустанавливали, так что все кеши точно почистились - и ничего не изменило.

(35) Не формируется с главной или не загружается в дочернюю? А обновление через cf'ник нормально проходит?
(36) Имел ввиду кэш дочерней базы.

вышла из ситуации так: сделала копию главной базы, а из ней сделала дочернюю:
1) название дочернего узла и код написала где главный узел, а название и код главного на место дочернего
2) остальные дочерние узлы в плане обмена удалила
3) в новой дочерней базе изменила номера сообщений обмена на 0
и очистила регистрацию для узла
4) обработкой типа "реанимация подчинённого узла" установила главный узел
5) выгрузила сообщение из главной в дочернюю, а потом уже в дочерней загрузила выгрузила
И всё пошло и поехало.

Не хочу расстраивать тс, но "пошло и поехало" - временное явление. Причина возникновения проблеммы - невыявлена и неустранена. Высока вероятность повторного рецидива.

PS: И никто не советовал проверить конфигурацию. Почему? Почему то никто не посоветовал сравнить конфигурации - основную с конфигурацие базы данных или основную с неё же самой выгруженной...

(32) у нас к сожалению периферийный базы выключают на ночь. Обмен делается днем.

(39) А что делать если окажется, что конфигурация базы данных отличается от её самой выгруженной интересно?