Profile общий, но у одного юзера он свой

[imendan]

Здравствуйте, господа профи! Странное дело. У меня есть профайл одной БД, общий для всех юзеров. Но у одного юзера он почему-то свой и никак не увидит изменения сделанные Админом.
Дабы исправить ошибку я удалил все профайлы и под админом создал заново. Но, снова у юзера свой профайл.
Далее я даю этому юзеру полный доступ с удалением. Под его учеткой удаляю все профайлы. Под админом создаю профайл. Та же беда.
Есть ли мысли почему так происходит? Как мне почистить левые профили?

Пробовал под Full access админом делать. Использовал агенты с Full Administration правами.

 

[Gandliar]

Профильные документы (в понятии лотуса) есть смысл делать для каждого пользователя свой.
Если нужно сделать общий и меняемый еще админом - лучше сделать обычный документ для этого.

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

 

[alexas1]

Профильные документы (в понятии лотуса) есть смысл делать для каждого пользователя свой.
Если нужно сделать общий и меняемый еще админом - лучше сделать обычный документ для этого.

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

...... - при работе из под клиента
В вэбе совсем другая картина

 

[imendan]

Если нужно сделать общий и меняемый еще админом - лучше сделать обычный документ для этого.

А что делать с производительностью? Когда все формы открываются и каждая обращается к документу (я так понял через @DBLookUp. Мне кажется это существенно повлияет на скорость открытия форм. Или я ошибаюсь?

 

[Gandliar]

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

Вообще надо понимать конечную задачу. А от нее уже смотреть варианты решений.

Есть некая настройка.
Есть некая форма.
В форму должно попадать значение из настройки.
И тут куча вариантов.
Значение должно попадать при создании формы разово.
А может должно обновляться при каждом обновлении/сохранении формы
Как часто обновляется настройка, допустимо ли кэширование
Нужна ли репликация настроечного документа
Сколько дблукапов, вариант с формулой и скриптом

 

[NetWood]

...... - при работе из под клиента
В вэбе совсем другая картина

А какая эта картина на вебе?

Даже при наличии удобной команды @GetProfileDocument я отказался на вебе от его использования и извлекаю настройки из дминистративного дока лукапом.
Со вьюхами беда. Но можно сделать лукап в свойствах колонки.

Профильдок то не реплицируется, то кешируется. В общем, ведет себя как женщина.

 

[alexas1]

А какая эта картина на веб

- жёсткий кеш в браузере. Если в клиенте, профайл можно использовать как приватный буфер, то в вэбе этот фортель просто так не пройдет (сбрасывать кеш себе дороже)