Запрет входа в базу под одним и тем же пользователем на ПК (1С 7.7, конф. не типовая)
Показывать по
10
20
40
сообщений
- 1
- 2
22.09.2010
15:45
#11
Я так понимаю что у любого юзера ты создаёшь локальный файл-маячок по наличию данных в котором проверяешь, зашёл пользователь в систему на данном клиенте или нет.
И по стандартному условию этот файл располагается на диске С как на томе со стандартным именем которое в любом случае присутствует в системе.
Ну на такой случай есть более элегантное решение уже реализованное в платформе.
Как мы помним, в настройках пользователя можно задать рабочий каталог. В случае наличия такого каталога система пишет в него файл блокировки соединений, и при попытке повторного входя пользователя выдаёт транспарант "каталог пользователя занят".
В демках типовых решений (конкретно в ТиС-е) такой приём реализован в виде указания относительного пути (например "./user1")
При этом каталог пользователя создаётся в каталоге БД.
Соответственно прописав в это поле не относительный а явный путь можно получить следующий результат.
Пользователь (к примеру) "Мария" каталог пользователя (опять же к примеру) "C:\1C_Users\Masha".
В этом случае получаем следующее. На клиенте создаётся каталог "C:\1C_Users\Masha" в котором система создаст файл 1Cv7.LCK. Вот он то и не пустит вторую "Марию" на данном клиенте.
Если же "Мария" паралельно соберётся войти в базу с другого клиента, то на данном клиенте будет создан свой локальный каталог и файл блокировки в нём. Таким образом наличие каталога с файлом блокировки на одном клиенте не помешает "Марии" войти в базу ещё раз с другого клиента.
Дополнительным плюсом будет ещё и то, что у "Марии" на каждом клиенте в своём каталоге будет создан свой конфигурационный файл параметров. Так что если у "Марии" на одном клиенте к примеру стандартным интервалом журнала будет "текущий год" то на другом можно сделать "текущий месяц". (Получаем некоторый прототип модели разделения пользовательских настроек по аналогии с реализованным в механизмах платформы 8 версии).
З.Ы. Малю-ю-ю-ю-сенькое неудобство... Каталог "C:\1C_Users\Masha" на клиентах перед первым запуском придётся создавать вручную, так как если при входе система его не обнаружит, то выругается на его отсутствие и базу не запустит.
З.З.Ы. Кстати, даже после аварийного вылета из базы, проблемы с оставшимся файлом не существует, потому как система при входе юзера проверяет не само наличие файла блокировки в каталоге пользователя, а доступ к операциям над ним, которые в случае имеющегося работающего пользователя ограничиваются только чтением. И именно ошибка захвата файла для удаления перед повторным его созданием как раз и транслируется системой в виде вышеупомянутого транспаранта.
Дальше всё ограничивается только вашей фантазией
И по стандартному условию этот файл располагается на диске С как на томе со стандартным именем которое в любом случае присутствует в системе.
Ну на такой случай есть более элегантное решение уже реализованное в платформе.
Как мы помним, в настройках пользователя можно задать рабочий каталог. В случае наличия такого каталога система пишет в него файл блокировки соединений, и при попытке повторного входя пользователя выдаёт транспарант "каталог пользователя занят".
В демках типовых решений (конкретно в ТиС-е) такой приём реализован в виде указания относительного пути (например "./user1")
При этом каталог пользователя создаётся в каталоге БД.
Соответственно прописав в это поле не относительный а явный путь можно получить следующий результат.
Пользователь (к примеру) "Мария" каталог пользователя (опять же к примеру) "C:\1C_Users\Masha".
В этом случае получаем следующее. На клиенте создаётся каталог "C:\1C_Users\Masha" в котором система создаст файл 1Cv7.LCK. Вот он то и не пустит вторую "Марию" на данном клиенте.
Если же "Мария" паралельно соберётся войти в базу с другого клиента, то на данном клиенте будет создан свой локальный каталог и файл блокировки в нём. Таким образом наличие каталога с файлом блокировки на одном клиенте не помешает "Марии" войти в базу ещё раз с другого клиента.
Дополнительным плюсом будет ещё и то, что у "Марии" на каждом клиенте в своём каталоге будет создан свой конфигурационный файл параметров. Так что если у "Марии" на одном клиенте к примеру стандартным интервалом журнала будет "текущий год" то на другом можно сделать "текущий месяц". (Получаем некоторый прототип модели разделения пользовательских настроек по аналогии с реализованным в механизмах платформы 8 версии).
З.Ы. Малю-ю-ю-ю-сенькое неудобство... Каталог "C:\1C_Users\Masha" на клиентах перед первым запуском придётся создавать вручную, так как если при входе система его не обнаружит, то выругается на его отсутствие и базу не запустит.
З.З.Ы. Кстати, даже после аварийного вылета из базы, проблемы с оставшимся файлом не существует, потому как система при входе юзера проверяет не само наличие файла блокировки в каталоге пользователя, а доступ к операциям над ним, которые в случае имеющегося работающего пользователя ограничиваются только чтением. И именно ошибка захвата файла для удаления перед повторным его созданием как раз и транслируется системой в виде вышеупомянутого транспаранта.
Дальше всё ограничивается только вашей фантазией
23.09.2010
11:00
#13
> Я так понимаю что у любого юзера ты создаёшь локальный файл-маячок по наличию данных в котором проверяешь, зашёл пользователь в систему на данном клиенте или нет.
Верно, по наличию файла маячка проверяю есть ли вход под данным пользователем на данном ПК.
> Дополнительным плюсом будет ещё и то, что у "Марии" на каждом клиенте в своём каталоге будет создан свой конфигурационный файл параметров.
А вот этого как раз и не надо, конфигурационный файл параметров должен быть единый.
Я думал над реализацией выноса рабочей папки пользователя на локальный ПК, но в конечном итоге столкнулся с тем, что надо таскать по сети с сервера папку пользователя на локальный ПК при его входе и обратно на сервер при его выходе... За морочиться конечно можно, но уже не средствами 1С... Но это может быть тема для отдельного топика. Да и тут же опять становиться вопрос о контроле количества сессий пользователя.
Верно, по наличию файла маячка проверяю есть ли вход под данным пользователем на данном ПК.
> Дополнительным плюсом будет ещё и то, что у "Марии" на каждом клиенте в своём каталоге будет создан свой конфигурационный файл параметров.
А вот этого как раз и не надо, конфигурационный файл параметров должен быть единый.
Я думал над реализацией выноса рабочей папки пользователя на локальный ПК, но в конечном итоге столкнулся с тем, что надо таскать по сети с сервера папку пользователя на локальный ПК при его входе и обратно на сервер при его выходе... За морочиться конечно можно, но уже не средствами 1С... Но это может быть тема для отдельного топика. Да и тут же опять становиться вопрос о контроле количества сессий пользователя.
23.09.2010
11:04
#14
Вариант хороший, но немного не подходит в результате хранения файла конфигурации не на сервере а на локальных ПК...
23.09.2010
12:26
#15
> Я думал над реализацией выноса рабочей папки пользователя на локальный ПК, но в конечном итоге столкнулся с тем, что надо таскать по сети с сервера папку пользователя на локальный ПК при его входе и обратно на сервер при его выходе...
Не совсем понятно зачем это нужно, раз ты изначально пытешься создать маячок локально.
А вообще ещё можно обратить внимание на ключ /U командной строки запуска 1с 7.7
> А вот этого как раз и не надо, конфигурационный файл параметров должен быть единый.
делаем скрипт, которым сначала таскаем "образцовый" CFG с сервера в локальный каталог пользователя, а потом уже вызываем запуск 1С.
Используется файл-сервер или клиент-сервер?
Если файл сервер, то цепляется как клиент по сети или через терминал?
Судя по первоначальному описанию задачи, вариант с созданием локальных каталогов пользователя на клиентах, является самым оптимальным.
Может ты чего-то ещё не указал?
Не совсем понятно зачем это нужно, раз ты изначально пытешься создать маячок локально.
А вообще ещё можно обратить внимание на ключ /U командной строки запуска 1с 7.7
> А вот этого как раз и не надо, конфигурационный файл параметров должен быть единый.
делаем скрипт, которым сначала таскаем "образцовый" CFG с сервера в локальный каталог пользователя, а потом уже вызываем запуск 1С.
Используется файл-сервер или клиент-сервер?
Если файл сервер, то цепляется как клиент по сети или через терминал?
Судя по первоначальному описанию задачи, вариант с созданием локальных каталогов пользователя на клиентах, является самым оптимальным.
Может ты чего-то ещё не указал?
23.09.2010
13:08
#16
> > Я думал над реализацией выноса рабочей папки пользователя на локальный ПК, но в конечном итоге столкнулся с тем, что надо таскать по сети с сервера папку пользователя на локальный ПК при его входе и обратно на сервер при его выходе...
>
> Не совсем понятно зачем это нужно, раз ты изначально пытешься создать маячок локально.
Это к данному топику не относится.
>
> А вообще ещё можно обратить внимание на ключ /U командной строки запуска 1с 7.7
>
> > А вот этого как раз и не надо, конфигурационный файл параметров должен быть единый.
>
> делаем скрипт, которым сначала таскаем "образцовый" CFG с сервера в локальный каталог пользователя, а потом уже вызываем запуск 1С.
Тут вопрос в том как отследить под каким пользователем будет осуществляется вход в базу и соответственно какую папку тянуть с сервера, а при выходе "в куда" файлы настроек и т.п. возвращать... Можно конечно сделать свою форму входа для пользователя, с выбором базы, вводом имени и пароля, копировать соответствующую папку с сервера на локаль, а 1С потом запускать с параметрами, но тут уже писать надо... и пароль и имя хранить и в 1С и в программе для входа пользователя...
>
> Используется файл-сервер или клиент-сервер?
> Если файл сервер, то цепляется как клиент по сети или через терминал?
>
Обычны файл-сервер, цепляется как обычный клиент \\ИмяСервера\Диск\ПапкаБазы\
> Судя по первоначальному описанию задачи, вариант с созданием локальных каталогов пользователя на клиентах, является самым оптимальным.
>
> Может ты чего-то ещё не указал?
Ну я даже не знаю, что еще нужно.
Задачу поставленную перед собой я вообще-то уже решил.
А по поводу таскания рабочей папки с сервера на локаль и обратно на работе пока заморачиваться не хочу... надобности нет. Только разве, что из академического интереса, но это тогда уже дома, если будет интересно можно попробовать, пишите.
>
> Не совсем понятно зачем это нужно, раз ты изначально пытешься создать маячок локально.
Это к данному топику не относится.
>
> А вообще ещё можно обратить внимание на ключ /U командной строки запуска 1с 7.7
>
> > А вот этого как раз и не надо, конфигурационный файл параметров должен быть единый.
>
> делаем скрипт, которым сначала таскаем "образцовый" CFG с сервера в локальный каталог пользователя, а потом уже вызываем запуск 1С.
Тут вопрос в том как отследить под каким пользователем будет осуществляется вход в базу и соответственно какую папку тянуть с сервера, а при выходе "в куда" файлы настроек и т.п. возвращать... Можно конечно сделать свою форму входа для пользователя, с выбором базы, вводом имени и пароля, копировать соответствующую папку с сервера на локаль, а 1С потом запускать с параметрами, но тут уже писать надо... и пароль и имя хранить и в 1С и в программе для входа пользователя...
>
> Используется файл-сервер или клиент-сервер?
> Если файл сервер, то цепляется как клиент по сети или через терминал?
>
Обычны файл-сервер, цепляется как обычный клиент \\ИмяСервера\Диск\ПапкаБазы\
> Судя по первоначальному описанию задачи, вариант с созданием локальных каталогов пользователя на клиентах, является самым оптимальным.
>
> Может ты чего-то ещё не указал?
Ну я даже не знаю, что еще нужно.
Задачу поставленную перед собой я вообще-то уже решил.
А по поводу таскания рабочей папки с сервера на локаль и обратно на работе пока заморачиваться не хочу... надобности нет. Только разве, что из академического интереса, но это тогда уже дома, если будет интересно можно попробовать, пишите.
- 1
- 2
Читают тему
(гостей: 1)