Доброго времени!

Господа, про это зло после динамического обновления написано очень много, но я нашел себе новые грабли.
Обновление производится через дополнительную софтину, запущенную под системным пользователем System, котороя подключается к базе через COMConnector. С некоторого времени, после обновления начали всплывать старые косяки в коде, которые лечатся очисткой кеша и новым обновлением. Но в таком случае это выполняется уже под локальным пользователем, руками, и при следующем автоматическом обновлении все повторяется.
%UserProfile% для System выдает путь
C:\Windows\System32\config\systemprofile\AppData
По которому, 1Совского кеша нет.
Вопрос, что бы почистить такого?)

скрытые файлы в C:\Windows\System32\config\systemprofile\AppData ?

https://technet.microsoft.com/ru-ru/sysinternals/bb896645.aspx

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

(2) и как влияет клиентский комп, кроме работы во время дин. об.?

(3) кэш открывается на клиентском компе.
И создается на нем заново без всякого отношения к режиму обновления. На тех компах, что стоят в нашей орг. от вида обновления (динамическое или монопольное) поведение не зависит. Есть базы, которые их саппорт обновляет ТОЛЬКО монопольно, но это их не спасает.

(4) Так то КЭШ у 1с страшная штука, в плане реализации сего механизма :)

Вся прелесть в том, что проявляется у всех пользователей, включая администратора одинаково и простая очистка локального кэша с перезапуском не помогают, только новое обновление.

(4) я не говорю, что ошибки только при дин.об.
если обновили объект динамически, а этот объект уже открывался на клиенте, не вероятность глюков будет выше

(6) а если кэш сервера?

(8) Остановка службы, очистка серверного и локального кэша с новой регистрацией базы в кластере не спасают без нового обновления :)

(9) А если выгрузить конфигурацию ИБ и сравнить ее с основной конфигурацией? жуть... мало того, что глючит на клиенте, так еще и содержимое конфигурации базы глючит.

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

(11) Возможно это зависит от конкретного сервера, в смысле от того, что на нем закешировалось

(12) а ведь очень похоже, что глючит все-таки клиентский комп, с которого происходит запуск в режиме Конфигуратор.
У меня при переходе на версию 8.3.5.1383 стала глючить хранилище конфигурации. Перестал им пользоваться. Могу предположить, что глюки при работе с хранилищем как-то похожи с тем... Стоп!!!
А ведь я как раз и перестал использовать хранилище конфигурации, потому что у меня в базе на сервере постоянно стали выскакивать версии модулей, не совпадающие с разработкой в локальной базе, но которые я пихал на сервер через конфигурацию хранилища.

(13)Очень похоже! То есть косяк все таки в цфнике, выгруженном из хранилища? о_О

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