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

fraks,

Это понятно. Подобный вариант первый пришел на ум. Думалось может без своего велосипеда можно что-то сделать.

hvlad,

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

Насчет резервирования таблиц я тоже задумывался. Спасибо за совет, Влад. Но решил, что табличка подключений, которую присоветовал fraks в реализации попроще будет. Тем более, что если сделать структуру похожей на mon$attachments, то и менять нужно будет очень мало. В общем уже сделал.

Dimitry Sibiryakov,

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

Симонов Денис,

По сути твое замечание верно, но я не зря в первом посте сделал оговорку насчет масштабов базы/приложения. Выгнать юзеров на время закрытия не большая проблема. Сама процедура длится не больше пяти минут со всеми архивированиями. Плюс пользователи видят перед собой текущий период. Если они не закрывают приложение, то нужно что-то мутить с событиями, чтобы понять в какой момент текущий период должен стать прошлым.

За советы спасибо. Насчет EXECUTE STATEMENT тоже подумывал, но решил, что реализовать свою attachments проще

Dimitry Sibiryakov,

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

Сразу не увидел твой пост.
Да все так.
Ответил уже Симонову Денису. Его замечание было практически аналогично твоему.

Состояние периода (открыт/закрыт) реализовано несколько иначе. Есть таблица итогов, а не периодов. Записи там появляются как раз в момент закрытия. Соответственно незакрытым считается период , следующий за последним в этой таблице. Он же текущий если пользователь не переключился на более ранний. Переключиться кстати могут не все. Если пользователь переключился на более ранний, то текущий и незакрытый периоды не совпадают, и в этом случае изменения запрещены.

Насчет сбоев спасибо. Реализую наверно в кроне удаление зависших записей.

Чтобы развеять мнение насчет неудобств пользователям, создаваемым требованием выхода на момент закрытия.
Такая схема работает уже очень давно. Лет двадцать, не меньше. Само приложение я перевел недавно на firebird с другим гуем. До того было сделано на древнем парадоксе. Менять всю схему приложения даже мыслей не было. Потому что в одиночку (а больше некому) чересчур сложно, да и пользователи нифига не оценят, скорее наоборот. Сама проблема коннектов и предупреждения возникла в этом году. Приложением захотела попользоваться еще одна автобаза. Наши и так административными мерами запрещали вход в программу пока идет сверка всех отчетов перед закрытием. Саму сверку проводят один, два человека. Ну а само закрытие естественно один. А вот у соседей замечал, что в момент закрытия не все пользователи выходят. Вот и решил подстраховаться чтобы не было возможности сделать критическую ошибку.

Поразмыслив решил таки, что своя attachments с триггерами и постоянной проверкой, что какое-то подключение может сбойнуть и не удалить себя слишком геморно и не надежно. Решил использовать execute statement ... as user ... . Но получилось сделать только с SYSDBA. А других пользователей firebird кроме SYSDBA у меня нет. Используется trusted authentication. Не очень хочется светить пароль sysdba. Свою учетку я примапил во всех базах к роли RDB$ADMIN. Вопрос - можно как-то ее использовать?

Что-то не могу никак сообразить. С сисдба получилось сразу:


В варианте с доменной учеткой всегда посылает к администратору за логином фаерберда.
Или имелось в виду завести пользователя фаерберд для этого случая?

hvlad,

Я совсем запутался. Я думал, что если не указывать as user, то будет current_user.

Локального коннекта быть не может. Сервер и база находятся на другом компе. Примеры выполнял в ibexperte. Соединение указывал remote tcp/ip, ip-адрес сервера, алиас базы.

Попробовал убрать as user оставил role 'rdb$admin'. На роль никак не отреагировал. Просто выдал все коннекты текущего пользователя как если ввести простой 'select * from mon$attachments'. Только без звездочки, а с полями из примера.

hvlad,

Так ты on external имел в виду? Ну что ж. Спасибо за терпение. :)
Такой вариант:

сработал. Правда вначале тоже выдал только одну запись с юзером с именем сервака в домене. Но после того как подмапил ему роль rdb$admin уже получил все. Плюс еще одну правда, но это уже мелочь. Еще подумалось, что это нехилая такая дыра в безопасности получается.