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

как лечить последствия демонического обновления? - что за вопрос в пятницу?)))

Демоническое обновление зло.

да, может.

(1) Первая половина пятница считается рабочей)) так что можно до обеда)

(3)а как отследить что повисла конфа? в sql таблицах можно как то венрсионность найти этих конфигураций, и по идее у этих конфигураций при обновлении динамическом существуют приоритеты, как их получить?

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

(0) Возможно.

(5) Нет, проблема возникает внутри самой конфигурации.

(6) получается для исправления последствий демонических обновлений нужен 1с программист-экзорцист ))

Кэш почистить предлагали?

(9) Кэш на сервере? а эти конфигурации в кэше зависают?

(10) Нет, кэш у клиента. Может помочь.

(11) а если клиентов 1000, и одного зависла старая конфа, то как его найти?

(12) Он тебе сам позвонит

(13) а если какая мелочь, типа заполнения табличной части какого нибудь документа, а в табличной части 500 строчек, поменяли обработку заполнения и стало заполняться на 501 строку...это может вскрыться через достаточное длительное время

(14) Если прям так боишься - сделай пользователям запуск с ключем клиркэш =)

(15) тоже не выход, у пользователей есть настройки(хотя бы настройки печати), все время их сносить тоже не выход

(16) тавтология какая то получилась у меня

(16) Либо чисти кэш у пользователей, либо не используй динамическое обновление

(0) делайте перед демоническими обновлениями копию таблицы конфигурации в специально созданную для этого пустую базу. В случае проблем после демонического обновления - ее восстановить - 5 минут. У меня, правда с демоническим обновлением только один раз проблема была.

+(19) описание таблетки тут: http://habrahabr.ru/sandbox/70796/ .

(20) спасибо,сейчас почитаю

(14) В типовых есть внешние обработки заполнения ТЧ.

(19) Проблема с демоническим обновлением в том, что вылезти она может не сразу, а через полгода, например...

(22) на такое не наступал. Но честно не вижу - в чем трабла. Сохранил конфигурацию в cf. С нее сделал базу со здоровой конфигурацией.

(23) конфигурация в базе не отличается от сохраненной. Она на одном из клиентов отличается от конфигурации базы и только при работе. Тут обновление не поможет - изменений в конфигурации базы нет.

(23) Да ты не о том пишешь. (24) Прав

(0) На инфорстарте покапай, там куча готовых решений.
Вот например
http://infostart.ru/public/201394/

(26) оо,вот за это отдельное спасибо

(5) Есть версионность. Получить можно. Подробности не помню :) Копался, когда лечил базу после краха от ДО.

(28) в таблице congig скорее всего, в ms sql такая таблица доступна, но на postgre почему-то такой таблицы не видно

(23) В cf'ке может быть несколько экземпляров одного и того же объекта. Используется первый найденный. Некоторое время первый найденный может быть правильным. А потом что-то меняется - и первой находится старая копия... причем не факт что Конфигуратор и Предприятие первой будут находить одну и ту же копию.