Доброе время суток:
 Живет у нас  1C8.2(на одной машине) в связке сервер SQL2012 (другая машина) и все вроде бы мирно было.
НО в последнее время случилась беда: при обновлении базы, пользователи добровольно не выходят и программист убивает их сесси в менеджере 1С, начинает обновление и получает "висяк 1С". Какой-то зависимости не наблюдается, 2 дня нормально, потом может виснуть при обновлении 1-3 дня, или днем 2 обновления нормально, потом все висим.
 Для возврата к работе спасают нехитрые манипуляции, остановка службы 1C8 на сервере приложений, "детач" и "атач" базы в SQl и перезапуск службы SQL. Запуск службы 1С8. (иногда спасает облегченный вариант - просто "детач" и "атач" базы).
Понимаю, что на SQL зависают сессии, но дальнейшие действия пока не укладываюся в голове...
З.Ы. имеется еще связка 1C 8.2 & sql 2012 и таких проблем не возникает.

"добровольно не выходят и программист убивает их сессии" - оторвать руки прогеру. А за "днем 2 обновления нормально, потом все висим" и за "нехитрые манипуляции" - уволить за профнепригодностью.

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

Куясе манипуляции... детач-атач

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

Demiurg, cпасибо.

Попробую вынести базу в отдельный кластер 1С.

да, уволить.

MAxus43 - всех уволить ?  
Выход однако.

(7) см 1, там подробней)

(7) Да, за профнепригодность

(0) Типичная проблема кэша.

Из-за аварийного снятия приложения в оснастке 1С кэш остался на локальной машине старый, а базу обновили... Поэтому либо выше изложенный танцы с бубном, либо при таких случаях просто принудительная очистка кэша на соответствующей локальной машине