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

Ага, я всегда так говорю: чего гадать, надо попробовать

хорошо когда есть с кем посоветоваться

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

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

Получаем - что лучше хранить где-то и обновлять отдельно...

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

Вот если бы повесить на объект-пользователь Триггер по изменению master..sysprocesses.
Таблица изменилась-триггер обновил атрибут - вот это было бы то что нужно.

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

итак..
есть несколько новостей.

1. запрос

Код: Выделить всё

select distinct empl.loginname
from master..sysprocesses 
join 
lsdbo.empldb_v empl
on 
master..sysprocesses.loginame =  
empl.loginname
where user_id = 299

с успехом выполняется простым пользователем.

2. если в вычисляемом поле на форме объекта-сотрудника написать вот так:

Код: Выделить всё

if(
f_ExecSQLSelect_2('select distinct empl.loginname
from master..sysprocesses 
join 
lsdbo.empldb_v empl
on 
master..sysprocesses.loginame =  
empl.loginname
where user_id = '+a100000076000003+'','','')<>'', 'В сети' , 'Не подключен')

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

. правда, при сохранении этого выражения в вычисляемое поле Лоция говорит о какой то ошибке (интересно, само по себе выражение проверяется, но когда тыкаешь ОК, чтобы закрыть окно редактирования выражения, - то появляется ошибка), но при этом все работает нормально.

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

гораздо удобнее было бы, если бы была функция, что то вроде f_UserConnected(<user_ud>), которая бы возвращала 0 или 1.

хотя то, что есть уже сейчас, тоже можно использовать.

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

и не нужно придумывать ни работы, ни триггеры...

Александр, или все таки есть аргументы в пользу атрибута?

да никаких, сам понимаешь,

все что нужно - макимально быстро получить информацию

если можно быстро-то и атрибут не нужен
если нельзя - то без него никак.

хотя поторопился

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

ну это ладно -ушел в сторону.

Короче если скорость будет -то никакие атрибуты не нужны и точка.

о, кстати! насчет динамических запросов.

я завел новую тему в другой ветке, но пока по ней - полный игнор (хотя есть просмотры).

поэтому вставлю сюда ссылку:
http://www.lplm.ru/phpBB2/viewtopic.php?p=830#830

может быть, здесь как раз сможет помочь EXECUTE?
если создавать запрос из нескольких блоков? я такое попробовал в отчете, но там оказывается EXECUTE вообще не проходит, уже написал в Теххелп, обещали посмотреть...
кто как эту проблему у себя решал?

извините за оффтопик

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

я тут покурил...

подумал...

есть 100% аргумент за атрибут применительно к атрибутивной форме
На мой взгляд нельзя вставлять запрос в вычисляемое поле, т.к. этот запрос выполняется постоянно (???? как работает вычисляемое поле на атрибутивной форме???? кто нибудь знает????) и грузит сервер-что если утебя твои 400 пользователей откроют каждый свою атрибутивную форму и будут смотреть на свою активность

- я думаю сервер умрет

хм, все таки есть проблемы с использованием запроса в форме.
во первых, ни с того ни с сего при просмотре формы, на которой есть поле с запросом, выскакивает та же ошибка, что была при настройке выражения:

Код: Выделить всё

Ошибка доступа к БД  (Function f_ExecSQLSelect Error [P0])
Код ошибки: 0
Текст ошибки:

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

судя по Profiler У пустой Лоции идет обмен с сервером
всегда
- 1. с интервалом на чтение почты, (повторяющийся запрос)
по событию
- 1. при заходе на диалог с исследуемым вычисляемым полем выполняется один запрос
- 2. при изменении габаритов диалога дерева проекта отдельно по периметру идет 2 запроса наверно первое положение и последнее
- 3. при перетаскивании всего диалога дерева проекта тоже 2 запроса
- 4. при перемещении внутри диалога границы между самим деревом и формой идет самая активная работа-запросы вылетают пачками

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

PS Кстати о заходе за другое окно, если на форме используется вычисляемое поле со следующим цветом фона

Код: Выделить всё

RGB ( 120+rand(135),  180+rand(75), 120+rand(135) )

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

PPS Все таки это глюк движка (Delphi'йского ядра) Лоции - по другому объяснить не могу.

(техподдержка на счет полосатости - промолчала, а больше и не спрашивал)

кстати ты видел как Лоция работает с данным полем?
вот
первый выход на объект типа пользователь (с другого типа объекта)

Код: Выделить всё

declare @P1 int
set @P1=241
exec sp_prepare @P1 output,NULL, N'select distinct empl.loginname
                                     from master..sysprocesses
                                             join
                                             lsdbo.empldb_v empl
                                             on
                                             master..sysprocesses.loginame = empl.loginname
                                    where user_id = 27',1
select @P1

Код: Выделить всё

exec sp_unprepare 241

изменение геометрии

Код: Выделить всё

select distinct empl.loginname
                                     from master..sysprocesses
                                             join
                                             lsdbo.empldb_v empl
                                             on
                                             master..sysprocesses.loginame = empl.loginname
                                    where user_id = 27

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

очевидные проблемы с перерасчетом функций при изменении геометрии (при записи функции было предупреждение-и соответсвенно здесь получите, только не понятно почему не всегда? -вот в чем вопрос!)

может явно указать - master.dbo.sysprocesses или через exec sp_who (/ sp_who2) поработать??

2 Anderyt
Куда пропал? чем там закончилось с теххелпом, я тоже спрашивал - молчат как партизаны

сорри, это все из-за работы

насколько я понял Теххелп, они пообещали исправить неровности при использовании функции ExecSQLSelect на формах объекта...
вот... ну что, ждем

Александр писал(а):PPS Все таки это глюк движка (Delphi'йского ядра) Лоции - по другому объяснить не могу

А там и не Delphi вроде, а Power Builder.

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

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

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

Как работать со списком подключеных к базе пользователей?