Интересует решение проблем некорретного выхода из 1С 7.7. (из терминалов и с простых компьютеров).
.
Лично я наблюдал два вида проблем возникающих в этом случае:
1.
Файлы \\server\1CDatabase\1Cv7.LCK; 1Cv7.$ui
файлы \\server\Юзер1,2,...,99\1Cv7.LCK
Файлы \\server\1CDatabase\1Cv7.LCK
остаются заблокированным - вход в 1С не возможен (у всех или у конкретного юзера - в зависимости от расположения лок-файла)...
.
Приходится заходить в остнастку администрирования "Управление компьютером" - "Открытые файлы" и прибивать их...

2.
Блокировка на SQL (не уверен что она связана только с некорректным выходом)
В базе остаётся блокировка процесса "Select NETCHGCN from _1SUSERS(NOLOCK)", т.е. при входе 1С-ка вроде бы как пытается получить кол-во действий пользователей, которые привели к изменению в базе данных, при этом хоть кол-во и равно 0 (а в базе никого нет) - дальнейшие запросы не идут...
.
Приходится опять же заходить в Enterprise Manager и Kill Process.
.
.
Это всё конечно хорошо, я разобрался как это без проблем быстро делать ручками, но как-то надо некрасиво каждый раз лезть на сервак ради этого... должны быть же какие-то средства для избавления от этих проблем.
Так например на одном из форумов я читал что для терминальщиков нужно настроить "Reconnect if disconnect...", тогда клиент потеряв коннект, будет при следующем коннекте "ловить" предыдущую сессию.
Или например пропатчивание на проверку блокировки 1Cv7.LCK.
.
.
Как вы решаете проблемы некорректного выхода?

(0) увидел шо выходят некоректно, сразу по башке им, по башке :)

Давайте не просто голосовать, но и пообсуждаем :)
.
Насколько вообще реально вычислить что пользователя выкинуло?
Так, вход регистритуется в лок-файлах и SYSLOG\links.tmp, существует ли какое-то событие по которому чётко можно определить что пользователь всё ещё работает в базе, и его не выкинуло... например поддерживается сетевое подключение к SQL.
Так, если будет чёткий признак того что пользователь находится в базе можно будет написать софтинку для сервера для периодической проверки РЕАЛЬНОЙ активности пользователя, и автоматизировать отрубление локов...

Если я не ошибаюсь на скуле есть табличка с подключениями, не помню как называеться, но что-то вроде sysproceses, а на дбф нужно лочить файл links.tmp

Таблица _1SCONNECT - Сессии (соединения)

Краткое описание: таблица предназначена для хранения уникального идентификатора сессии первого присоединившегося к базе данных пользователя в режиме предприятия (поэтому в таблице всегда только одна запись). Судя по всему, именно по наличию записи в этой таблицы и происходит верификация процедур при первом запуске в SQL.
Название поля    Описание
CONNECTUUID    GUID (уникальный идентификатор) первого сеанса, соединившегося с 1С в режиме предприятия. Тип - Строка(36).
.
.
Я ещё не пробовал проверять её содержимое при корректном/некорректном выходах...

Хотя предложенная вами таблица master БД, наверное будет более точна....

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

(7) - это я читал :)

(5)я имел ввиду: :)

Таблица _1SUSERS - Соединения

Краткое описание: таблица предназначена для хранения информации о подключенных пользователях. В таблице всегда одна строка. Именно по наличию строки в этой таблице 1С судит об аварийном завершении программы и предлагает переиндексировать ИБ в случае dbf-версии.
Название поля    Описание
USRSCNT    Количество подключенных пользователей к 1С в режиме 1С предприятия.
NETCHGCN    Счетчик действий пользователей, которые привели к изменению в базе данных (записи в таблицы). Счетчик учитывает количество записей в таблицы (т.е. в случае проведения документа с несколькими движениями учитывается каждое движение).
.
.
Хотя думаю её использование все равно не поможет... т.к. изменение данных таблицы происходит только при корректном выходе (насколько я понимаю)

(7) а если я в отпуск хочу? )))))

Чё так и будем ручками тыкать или напишем софтинку? :)
я на Делфи,С++,VB могу взяться :)

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

Дык просто времени нет сейчас :D
Да и в 1С ещё не мастер :)
вот и решил для начала пробить почву...
т.е. провести предварительную оценку предметной области и создать план...

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

(13) Это не всегда годится. За ночь может не успеть.

Если тебя небудет они накрайняк могут все выходить из 1с и перегружать сервак.
Потом заходить переиндексировать базу и работать.

Решил начать с блокировки на SQL процесса "Select NETCHGCN from _1SUSERS(NOLOCK)"
Но встал на проблемах различных версий SQL.
Так для получения текста последней комманды можно использовать fn_get_sql

http://technet.microsoft.com/ru-ru/library/ms189451.aspx
http://sqljunkies.com/WebLog/acalvett/archive/2006/03/27/19780.aspx

и простой код:
DECLARE @Handle varbinary(64);
SELECT @Handle = sql_handle FROM master.dbo.sysprocesses
SELECT * FROM ::fn_get_sql(@Handle);
GO
ничего не выдаёт на одних версиях, а на других уже отсутствует fn_get_sql....

ну ты монстер.

Не с того я начал... начать нужно с идентификации терминального юзера...

И не нужно прикалываться :)
не тупица я - вот:
http://forum.ishodniki.ru/index.php?action=profile;u=7732

p.s. не хвалюсь...