Lotsia PLM: Форум по семейству систем PLM/PDM/TDM/ERP/Workflow

Поделитесь опытом
Есть запрос MSSQL2000 например такой который показывает список пользователей подключенных к базе в настоящий момент.

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

ух ты... интересная идея!
спасибо за код!

хотя у нас задания распределяются в основном исходя НЕ из текущей доступности, подключен к серверу или нет... к серверу так или иначе всегда подключены все...

а как использовать? скорее всего, можно этот запрос объединить с другим, который будет оперировать ИД пользователей. иными словами, не список логинов, подключенных к серверу, а список ИД пользователей, подключенных к серверу. в докообороте ИД автоматом преобразуется в ФИО...

н-да, интересный, однако, подход...

В принципе да, не подумал, но у нас засада - список login пользователей свой, а список объектов пользователей свой (правда каждый из них содержит атрибут - ID пользователя базы) ...
и допустим, (к сожалению пока только в докобороте) можно бы ло бы одним SQL запросом отобрать пользователей, вторым SQL запросом отобрать подключенных и при выборе сотрудника, допустим по списку и фотографии - анализировать полученные массивы на пересечение и затенять фотографии неактивных.

Я просто чего спрашивал, может есть еще какие процедуры для этих целей, кроме

Идея! А что если на сервер автопереходов повесить работу которая будет с периодичностью в 30сек запускать данный запрос и по всем объектам пользователям устанавливать флаг (атрибут) тут он или нет.

Слушай Anderyt подскажи как это сделать? ведь это будет то что нужно!
- и интерфейс докоборота не нужен
- и никаких лишних наворотов
- и всегда свежие данные о юзерах

мне кажется, здесь можно обойтись и без списка объектов-сотрудников. если конечно не говорить о фотографиях или других атрибутах. атрибут ИД - это же вторичное явление, в начале был ИД пользователя, который хранится в lsdbo.empldb и в lsdbo.emplusers.

и можно кажется сделать это в одном запросе, средствами T-SQL, не доводя до пересечения массивов силами Лоции...

про затенение фотографий.... ну блин.... ну ваще.... мне бы вашу фантазию, Александр... 5 баллов!

так слушай, подскажи все-таки (пока мы в теме, в смысле мысль не ушла), как бы поработать на автосервере с 30 объектами сразу? или это будет сильно тормозить? или запустить 30 работ для каждого сотрудника персонально?

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

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

если объекты как то связаны по смыслу и можно сделать в работе массив с этими объектами - то можно вызывать действие по обработке для всего массива - оно будет вызвано для каждого объекта в отдельности.

но можно этот массив объектов формировать в действии и обрабатывать объекты в цикле в рамках одного действия. думаю, это самый быстроработающий вариант (и, как это обычно бывает, самый долгонастраиваемый). действие будет вызвано ОДИН раз, просто выполнятся оно будет небыстро. но мне кажется, что по времени обработки запустить 30 раз действие по обработке одного объекта - это не то же самое, что один раз по обработке 30 объектов...

Гм-м-м, а по-моему 30 раз инициализировать действие в сумме будет дольше, чем один раз

в том то и дело. я поэтому и говорю, что лучше массив объектов ормировать в действии и обрабатывать его в цикле...

Александр... хм... а ведь здесь пахнет данными о присутствии... нужно только найти способ, чтобы обновление этих данных не слишком тормозило автосервер, и тогда можно будет получить инфу, какие юзеры реально подключены... интересно...

Но если все известно заранее, то можно подумать об автоматической смене исполнителей. Или эмулировать ее автопереходами. Если первый в течение, например, 10 минут не отозвался - делать автопереход на эту же задачу, но другому юзеру.

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

думаю, здесь можно разделить задачи.

одно дело - когда мы хотим при выборе исполнителя следующего этапа видеть, в сети ли сейчас пользователь (я имею в виду, в НАШЕЙ сети, то есть подключен ли он к серверу БД). для этого можно использовать выбор следующего исполнителя из выпадающего списка, знчения которого будут формироваться динамически, и помимо каких то других условий (например, положения в организационной структуре), можно добавить в запрос условие "в сети?", как раз на основе того запроса, который привели вы, Александр, в самом начале. для этой задачи не нужны в принципе объекты-сотрудники и, следовательно, работа по установке каких-либо флагов для этих объектов.

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

вообще, нужно ли хранить эти данные в виде атрибута? как думаете?

и еще, самое главное запрос к master..sysprocesses может быть успешно сделан простым пользователем???

а сами по себе эти данные мне почему то интересны... я кажется видел где то в Office System 2003 такие штуки, разноцветные шарики, которые появляются рядом с каждой ссылкой на пользователя при наведении на эту ссылку. хотя мы это и не смогли завести (система для коллективной работы у нас все таки не Sharepoint + Office, а Лоция ПДМ + ), но думаю, что эти шарики как раз и показывают, в сети человек или нет... и кто его знает, может быть, в этой информации есть что то полезное для пользователей, раз Микрософт эту штуку сделал?

Сможет ли пользователь сделать сделать запрос к системным таблицам проще проверить Но что-то у меня родилась мысль, а не запросить ли разработчиков о возможности реализации функции, возвращающей флаг активности по ID юзера? Тогда можно будет ее везде подпихивать и не париться. Если только это не требует каких-то офигительных доработок

ух ты... интересно

хотя, имея ExecSQLSelect с запросом к master..sysprocesses и CurrentUserID (или как там правильно), можно получить этот флаг самим, не отвлекая разработчиков... блин, все забываю посмотреть, что же там в планах...

но вопрос про доступ юзеров к этой таблице остается пока открытым (завтра попробую).

и появился еще один вопрос - можно ли использовать ExecSQLSelect в вычислямых полях на атрибутивных формах и в отчетах??

Можно, только как показывает опыт, каждое движение мышкой по форме вызывает перечитывание запроса и крутящиеся часики. Ничего не тормозит, но часики крутятся. Это же вычисляемое поле - оно пересчитывается при каждом чихе.

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

завтра будет видно