У Вас возникали случаи, когда под одним пользователем в БД 1С заходит несколько лиц? И не коробит ли Вас, что остаются висеть сеансы при несанкционированном отключении питания?
В загрузке лежит фрагмент кода, который позволит Вам в пределах допустимого избежать подобных ситуаций (обычное приложение).
В загрузке лежит фрагмент кода, который позволит Вам в пределах допустимого избежать подобных ситуаций (обычное приложение).
Фрагмент кода необходимо разместить в модуль обычного приложения в Процедуру ПриНачалеРаботыСистемы, в самое начало процедуры. Обратите внимание на выделенные желтым имя сервера и имя БД на сервере (это Ваши данные).
Результат работ:
1. Если было несанкционированное отключение питания, тогда при последующем входе в БД будет удаляться висяк (дубль неубранного сеанса).
2. Если вход в базу осуществляется пользователем, который уже там есть, то его не будет пускать. Если непрошенка, то возникать не станет.
коль «трудяга», то возмутится и пожалуется на такое обидное и просто возмутительное и удручающее сообщение админу.
Рассчитано на программистов-системщиков, продвинутых админов 1С
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Кстати, интересно, а можно ли сыграть лицензиями так, чтоб добиться заявленного эффекта? Каждому выписывать лишь одну лицензию, т.е. фактически сделать их именными через всякие ini-файлы?
Если не ошибаюсь, но именно это уже давно реализовано в конфигурации УПП. Я доработал не просто вывод сообщения с кнопкой «ОК», а возможность завершить старый сеанс и запустить новый или отказаться.
я смотрел в УПП. Немного по-другому. Преимущество моей доработки в простоте внедрения. Мой вариант тож неплохой.
(1) Yashazz, лицензии дело хорошее :). без комментариев 🙂
Как быть в случае если пользователь в одном окне запускает длительный отчет или обработку, но ему надо еще и документы вводить?
В обычном режиме работы он просто откроет второе окно и будет работать.
Такие вопросы надо решать административным путем, а не городить огороды.
(5) Virikus, тоже верно. поэтому не все и решаются на использование данного алгоритма. Доработать выборность «уборки» сеансов — пару-тройку строчек в коде. Поэтому ориентир на программеров. Всегда лучше, если какие-либо защитные механизмы особенно для входа в БД сориентированы в одном месте. Кстати, этот код ориентирован на обычное приложение и для нестандартных конфигураций.
При доработке УТ_10.3 использовал механизм блокировки повторного входа в соответствии с Доп.Правами (специальная опция «Разрешить несколько сеансов»).
Кроме того была разработана специфичная роль, для которой разрешалось ровно 2 сеанса (в одном производилась длительная процедура печати пакета документов и второй сеанс для текущей работы).
Вот только автоматической выгонялки не делал. Предпочел изгонять пользователей руками Администраторов базы! Ведь можно иногда переподцепить потерянную сессию на терминальном сервере.
(7) V.Nikonov, если будет полнейшая автоматизация… то админы без работы будут ! Лучше, конечно, вручную. Но все равно уникальность нужна, чтоб висячими сеансами не засорять сервак. Естественно, прежде чем внедрять что-то, надо подумать нужно ли это именно вам.