|
И снова кеш | ☑ | ||
---|---|---|---|---|
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
|
косяк в головах разработчиков, которые проектировали (если такое вообще было) структуру-архитектуру восьмерки. Никакие кеши не должны вносить траблов. Кеш на то и кеш.
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |