8.х Не отключаются сессии пользователей по окончании работы (толстый клиент).

Добрый день! Помогите с проблемой.

Server 2008 Standart x64, SQL 2008 Standart, платформа 8.2.14.540... В консоли сервера 1С предприятие в соединениях показаны сессии (мало, но есть) пользователей длительностью в 5 дней и более. У самих пользователей никаких проблем с запуском и выходом из 1С нет. Утром включают компьютеры, вечером тушат...

Непотушенные сессии мешают архивации...

Насчет архивации через SQL я в курсе (сам давненько администратором являюсь). На мой взгляд с DT-шником все равно гораздо проще (по крайней мере если дома у тебя файловый вариант базы, а на работе SQL и часто приходится дописывать конфигурацию).

Хотелось больше уточнить насчет разрывов. По идее клиентская часть в таких случаях должна выкинуть пользователю в 1С соответствующее сообщение. Может конечно пользователи утаивают болячки и не говорят насчет выволочек... А сервер 1С никак не протоколирует завершения сессий?... к примеру штатно или нештатно завершила работу клиентская часть или были ли разрывы...

Вот про это и хотел узнать... А где глянуть более менее официальный вариант информации ?

Про разрывы, чтобы была возможность (не всегда правда "стреляющая") рубить сессии из консоли серверов 1С - это юзера, из под которого стартует сервер 1С в MS SQLе прописать, и задать ему роль processadmin

А по поводу бекапирования в DTшник - очень спорное утверждение по удобству.
Помимо медленной скорости есть еще и момент монопольности. Который, зараза ведь, критичен.

Вы делаете бэкап раз в сутки? Хорошо. А зачем Вы делаете бэкап? Наверное чтобы иметь возможность, в случае чего "откатиться" на один опердень. С потерей данных.
Хм. А сколько стоит один опердень вашей компании? Вот например в моей компании, один опердень стоит больше чем моя ЗП за... за квартал без бонусов.
Поэтому потеря целого дня (в случае, тьфу тьфу тьфу, краха сервера) - это ужос и страшный сон.
Однако, ежли мы пользуемся ср-вами MS SQL, мы можем в течении дня снимать оперативные бэкапы без требования монопольного доступа к БД. Например раз в четыре часа, или раз в два часа (можно и чаще, но тут нужно искать компромисс между снижением скорости работы сервера и надежностью хранения данных).

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

Для меня и для франчей, нас обслуживающих, скрипт расширен еще пунктами:
д) (по "флажку") завинрарить бэкап с паролем и выложить его на FTP + сетевую папку
е) стартануть развернутую БД с командой создания DTшника (/DumpIB)

Парни, давайте остановимся на сессиях... Формат бэкапа меня не интересует, т.к. в этой области я и сам разберусь как и когда мне архивить...

Больше интересует процесс подключения-отключения сессии толстого клиента на 1С Сервере предприятия, почему он может сбоить и как заставить проверять присутствие клиента.

Ну а если

И ставить не 0 секунд, а допустим 5

Uza, спасибо... Эту фишку я знаю...

Ладно, всем спасибо за ответы. Поковыряю Гилевские мануалы в Инете...