динамическое обновление и кэш. Информация к размышлению.
Столкнулся с неприятненьким. Может быть кому-то будет полезным.
Платформа 8.3.26.1581 Буха 3.0 серверная на мсскуле.
Итаг! Благословленное динамическое обновление.
У отдельного юзера(у всех остальных всё норм) после динамического обновления случилось интресное: начали вылезать ошибки с РЛС.
При запросах к БД начал подтягиваться Шаблон прописанный в РЛС... который не существует уже несколько лет.(лет5 примерно) Т.е. оно - старая, ОЧЕНЬ старая конфа , а скорее кусок обновления оной где-то внутри скуля всё ещё живёт.
Неожиданным оказалось то, что традиционная чистка кэша юзверя не дала эффекта. Оно живет где-то в профиле в самой БД. Ошибка устойчиво повторялась именно для данного пользователя на другом рабочем месте.
Перезапуск сервера тоже ничего не дал, и полное монопольное обновление, и динамическое обновление роли следом.
Я уже собрался лезть в скуль искать commit и прочее, но тут элементарно потыкал кнопочки прав доступа пользователя в справочнике. Выключил - включил. И всё зарабо....
Смысл. Думается мне, что в какой-то момент, 1С стала хранить часть кэша пользователя в самой БД. И это ниразу не прозрачно.
Кстати, для меня открытием стало и то, что теперь кэш разделён и хранится не только в Roaming, но и в Local. Чистить надо и там и там, и получается, это не всё...
поправка как здесь уточнил(2) часть кэша отвественная за последний введёный логин при входе переехала из Roaming в Local. сам кэш в локал был и ранее.
Платформа 8.3.26.1581 Буха 3.0 серверная на мсскуле.
Итаг! Благословленное динамическое обновление.
У отдельного юзера(у всех остальных всё норм) после динамического обновления случилось интресное: начали вылезать ошибки с РЛС.
При запросах к БД начал подтягиваться Шаблон прописанный в РЛС... который не существует уже несколько лет.(лет5 примерно) Т.е. оно - старая, ОЧЕНЬ старая конфа , а скорее кусок обновления оной где-то внутри скуля всё ещё живёт.
Неожиданным оказалось то, что традиционная чистка кэша юзверя не дала эффекта. Оно живет где-то в профиле в самой БД. Ошибка устойчиво повторялась именно для данного пользователя на другом рабочем месте.
Перезапуск сервера тоже ничего не дал, и полное монопольное обновление, и динамическое обновление роли следом.
Я уже собрался лезть в скуль искать commit и прочее, но тут элементарно потыкал кнопочки прав доступа пользователя в справочнике. Выключил - включил. И всё зарабо....
Смысл. Думается мне, что в какой-то момент, 1С стала хранить часть кэша пользователя в самой БД. И это ниразу не прозрачно.
поправка как здесь уточнил(2) часть кэша отвественная за последний введёный логин при входе переехала из Roaming в Local. сам кэш в локал был и ранее.
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
кэш всегда хранился в roaming и в local. По крайней мере всю 8.3 что я знаю. Там разные данные лежат.
Скорей всего тебе бы помогло почистить кэш полностью в обоих папках, либо, что проще, тупо удалить базу из списка баз на компе пользователя и добавить базу заново
Скорей всего тебе бы помогло почистить кэш полностью в обоих папках, либо, что проще, тупо удалить базу из списка баз на компе пользователя и добавить базу заново
(2) Чистил и там и там.
Просто раньше, чистки только Roaming всегда хватало, и при этом признаком успешной чистки был пустой логин при первом после чистки входе. Сейчас эта часть, похоже, переехала в Local, и как я написал, чистка обеих папок не помогла, Равно как и смена компа, т.е. исключения ЛЮБОГО кэша в винде. Помогло изменение данных в самой БД.
Просто раньше, чистки только Roaming всегда хватало, и при этом признаком успешной чистки был пустой логин при первом после чистки входе. Сейчас эта часть, похоже, переехала в Local, и как я написал, чистка обеих папок не помогла, Равно как и смена компа, т.е. исключения ЛЮБОГО кэша в винде. Помогло изменение данных в самой БД.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот