Всем доброе время суток.
Недавно перешли на 8.2 (платформа 8.2.15.289, конфигурация не типовая). И стала возникать следующая проблема. Периодически на некоторых рабочих станциях и на серваке после обновления конфигурации не видны изменения. Т.е. внёс я изменение скажем в модуль документа, оттестировал работу на тестовой базе, скинул конфигурацию в хранилище. После чего администратор или я обновляет из хранилища рабочую базу (иногда делаем обновление динамически). Ну я считаю что вопрос закрыт, а потом через пару дней обращается какой-нибудь пользователь с такой же ошибкой.
Тогда я захожу в конфигуратор рабочей базы с ПК пользователя смотрю в в модуль документа и вижу что там старая конфа. Причём всякие действия по сравнению конфигурации с хранилищем или выгрузки конфигурации в файл с проблемного и рабочего ПК и затем сравнение даёт идентичные конфигурации.
Проблема решается вводом пустых строк в проблемные модули и повторным обновлении конфы не динамически.
Раньше работали на платформа 8.1.12.101 и подобная ситуация возникала всего 1 раз. Сейчас проблема возникает до безобразия часто. На мой взгляд причина кроется в динамическом обновлении, либо обновлении через хранилище.
За сим вопрос. Может кто сталкивался с подобной проблемой? Хотелось бы услышать кто и как с сим боролся.

я, конечно, могу ошибаться, но мне кажется проблема в "иногда делаем обновление динамически".

(0) rd "%UserProfile%\Local Settings\Application Data\1C\1Cv82" /s /q
в cmd при закрытой базе.

(1) тоже склоняюсь к этой версии
Вот подобную проблему обсуждали тут на форуме
v8: Мутабельное значение

"На мой взгляд причина кроется в динамическом обновлении" да... и что теперь будете делать?

Зачем обновлять динамически? Нужно всем срочно? Или режим работы 24/7 ? Можно спокойно обновить в не рабочее время, батником из планировщика...

(1) А можно расшифровать
(4) Попытаюсь найти способ решения проблемы позволяющий обновляться динамически. Если не найдё, то придётся отказаться от динамического обновления.

2(6) окей, способ описан в (2)

(5) Иногда хочется закрыть вопрос сегодня не откладывая его на завтра.

(8) Я делаю так: Обновление конфигурации - сразу, обновление конфигурации базы данных - ночью.

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

(8) У меня проблема вылазила через месяц после того, как я добавил код. Причем вылетела примерно у 40% пользователей.
Лучше ближе к ночи на 5-10 минут зайти удаленно и обновиться.

(2)(7) Тока что почистил полностью Local Settings\Application Data\1C\1Cv82\ но проблема осталась.

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

2(12) окей, удали базу из списка и добавь заново

2(13) динамическим не будет считаться если не будет в это время ни один клиент помимо конфигуратора в этой базе.

(13) Нет, конечно. Речь именно о способе обновления конфигурации базы данных.
Но удобнее работать через хранилище, даже если ты единственный разработчик.

(14) не помогло

2(17) а где ты это сделал?

(15)(16)Т.е. термин "динамическое обнолвение" - только на момент F7.
Спасибо.

2(19) нет... и на Ф5 тоже, если в базе кто-то работает еще

(18)На своём компе.
почистил каталог Local Settings\Application Data\1C\1Cv82\ и удалил из списка баз рабочую базу затем добавил её опять и зашёл в предприятие. Ошибка осталась.

(19) Ну да. Ни разу не пробовал, что ли? Когда руками жмешь F7 а базе есть юзвери - предлагает или всех зарезать или выполнить динамическое обновление (если не было структурных изменений данных).

2(21) ошибка осталась на твоем компе или у того пользователя?

база серверная?

(19) Дополню: "Демоническое обновление" применимо только при изменении конфигурации базы данных и при работающих пользователях. При изменении остальных (основная конфигурация и конфигурация поставщика) не влияет.

(20) Понятное дело. Ф5 по дефолту пытается сохранить конфу, тут же обновить конфу БД и запустить предприятие в режиме отладки.
(21) На своем компе ты почистил свой кэш. А надо почистить кэш проблемного юзверя.

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

(26) Я сам и есть проблемный юзер

2(27) Ну так перезапусти сервер.. И еще почитай про ключ /ClearCache по Ф1

(22)Ни разу.
Зачем?
Если я заранее знаю о возможных проблемах долгого запуска и старого кода при динамическом обновлении - зачем это делать?
Но, иногда надо кое-что во время работы пользователей сделать, вот и уточняю.
Надеюсь, когда-нибудь 1С сделает все без проблем и по обновлению базы.

(29) ключ /ClearCache не помог. Сервак перегружать не вижу смысла проблемы же на рабочих станциях.

2(31) ыыыы... на сервере конфа тоже может закэшироваться.. тока так.

(2)(14)(29)(32) Ни чего из выше перечисленного не помогло, даже на клиенте 1С переустанавливал (правда не сносил а по верху).
Проблему получилось снять , только как и раньше добавил пробелы в проблемный модуль и обновил рабочую базу(не динамически). В результате проблема снялась у всех пользователей.
Резюмирую:
Причина возникновения скорей всего в динамическом обновление.
Лечить если всё же возникло добавить пробелы в проблемные модули и обновить конфу не динамически.
В общем ничего нового не нашёл.

v8: Демоническое обновление - зло абсолютное?

(34) Нашёл в этой ветке
Ошибки, исправленные при выпуске версии 8.2.15.273


10095297  Динамическое обновление

Проблема:
После нескольких динамических обновлений может проявляться нестабильная работа конфигурации - пользователи могут работать с неактуальными текстами программных модулей.
Способ обхода:
Очистить кэш метаданных.
Дата публикации: 2011-12-07

Я так понял это почистить \Local Settings\Application Data\1C\1Cv82 на ПК проблемного пользователя. Но мне это не помогло.

(35) вроде  \Local Settings\Application Data\1C\1Cv82 - это для файловой базы.

(36) А для SQL как сделать?

2(37) возможно тоже самое но на сервере и для пользователя usr1Cv82

(38)у меня есть в каталоге следующие папки
3f893b78-e718-4ce6-
7264abe9-9d75-4b19-
825470c4-d012-4914-
dumps
logs
reg_1841
srvribrg.lst
Первые 3 пустые. А остальные полностью удалять думаю нельзя. Что именно нужно удалить?

как раз первые три я думаю...
И еще есть вариант... удалит и добавить базу, но не на клиенте в консоли кластера серверов, указав в качестве базы СУБД ту же что была...

(4) Ну если почистить и так пустые папки
А с удалением базы завтра на тестовой попробую.

(2)(7) (21)(35) Всем спасибо. Получилось снять проблему:
Надо было чистить %UserProfile%\Application Data\1C\1Cv82, а не %UserProfile%\Local Settings\Application Data\1C\1Cv82.

(42) Удалять надо обе папки. Но в любом случае, это маразм.

Кто-нибудь знает, можно ли почистить кеш конфигураций на сервере? Происходит ли это при изменении структуры БД?

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

Что-то ссыкотно. :) А штатных средств нет?