Имя: Пароль:
1C
1С v8
И снова кеш
, , ,
0 Besometr
 
07.05.15
10:07
Доброго времени!

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

https://technet.microsoft.com/ru-ru/sysinternals/bb896645.aspx
2 Фрэнки
 
07.05.15
12:02
и между прочим, нет прямой связи между тем, что кэш конфигурации на клиенте портит именно динамическое обновление ИБ. Это больше зависит от поведения клиентского компа, чем от режима обновления иб
3 John83
 
07.05.15
12:07
(2) и как влияет клиентский комп, кроме работы во время дин. об.?
4 Фрэнки
 
07.05.15
13:16
(3) кэш открывается на клиентском компе.
И создается на нем заново без всякого отношения к режиму обновления. На тех компах, что стоят в нашей орг. от вида обновления (динамическое или монопольное) поведение не зависит. Есть базы, которые их саппорт обновляет ТОЛЬКО монопольно, но это их не спасает.
5 ЧеловекДуши
 
07.05.15
13:20
(4) Так то КЭШ у 1с страшная штука, в плане реализации сего механизма :)
6 Besometr
 
07.05.15
13:26
Вся прелесть в том, что проявляется у всех пользователей, включая администратора одинаково и простая очистка локального кэша с перезапуском не помогают, только новое обновление.
7 John83
 
07.05.15
13:30
(4) я не говорю, что ошибки только при дин.об.
если обновили объект динамически, а этот объект уже открывался на клиенте, не вероятность глюков будет выше
8 John83
 
07.05.15
13:32
(6) а если кэш сервера?
9 Besometr
 
07.05.15
13:37
(8) Остановка службы, очистка серверного и локального кэша с новой регистрацией базы в кластере не спасают без нового обновления :)
10 Фрэнки
 
07.05.15
13:49
(9) А если выгрузить конфигурацию ИБ и сравнить ее с основной конфигурацией? жуть... мало того, что глючит на клиенте, так еще и содержимое конфигурации базы глючит.
11 Besometr
 
07.05.15
13:55
(10) Вот выгружать не пробовал, но сравнение с тем же цфником, из которого была обновлена конфа ведет себя двояко. Иногда различие есть, но это бедный несчастный веб сервис, всегда один и тот же, но косяки не в нем. Иногда различий вообще нет.
12 Besometr
 
07.05.15
13:58
(11) Возможно это зависит от конкретного сервера, в смысле от того, что на нем закешировалось
13 Фрэнки
 
07.05.15
14:18
(12) а ведь очень похоже, что глючит все-таки клиентский комп, с которого происходит запуск в режиме Конфигуратор.
У меня при переходе на версию 8.3.5.1383 стала глючить хранилище конфигурации. Перестал им пользоваться. Могу предположить, что глюки при работе с хранилищем как-то похожи с тем... Стоп!!!
А ведь я как раз и перестал использовать хранилище конфигурации, потому что у меня в базе на сервере постоянно стали выскакивать версии модулей, не совпадающие с разработкой в локальной базе, но которые я пихал на сервер через конфигурацию хранилища.
14 Besometr
 
07.05.15
14:47
(13)Очень похоже! То есть косяк все таки в цфнике, выгруженном из хранилища? о_О
15 Злопчинский
 
07.05.15
15:54
косяк в головах разработчиков, которые проектировали (если такое вообще было) структуру-архитектуру восьмерки. Никакие кеши не должны вносить траблов. Кеш на то и кеш.