![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
(InterBase)Многопользовательский доступ к БД разных пользователей [D7, IB6.x]
DmitrichJ © (2006-06-30 00:06:00)Вот такой вот вопрос: Есть БД (InterBase 6) на сервере в которой есть список пользователей. Например Петров,Сидоров и т.д. Господин Сидоров запускает программу (подключается БД) выбирает себя из списка (к этому можно добавить пароль и т.п.) и начинает работу с данными. Всё хорошо. Господин Петров у себя запускает программу и...
1. Не мог бы зайти под именем Сидорова т.к. он сейчас работает с данными
2. Войдя под собой мог бы видеть кто сейчас работает с БД.
Заранее благодарю, уважаемые коллеги=) Вопрос очень важный!
Desdechado (2006-07-05 11:29:00) [1]Андрей Пазик (04.07.06 17:34) [23]
> Ты только никому этого не говори :)
Уверяю тебя, в любом софте есть ошибки. И то, что в IB6 нашли и исправили что-то в FB, это нормально. Причем эти "сотни" тянутся в большинстве своем еще с версии 5.0.
Да и в самом FB их не меньше.
Просто есть версии стабильные, а есть не очень. Так вот IB6, IB5.6 - стабильные, IB5.5 - совсем не очень.
А ошибка ошибке рознь. На некоторые ты за всю свою жизнь не наскочишь.
Я, например, гоняю сервера в очень разнообразных режимах. И (карма у меня такая) вечно ловлю какие-то глюки в любом софте. Так вот в IB я поймал только однажды некоторую недоработку, устранявшуюся через backup-restore. А в оракле, например, каждый месяц по глюку, который устаняется только очередным патчем. Один до сих пор с завидной регулярностью хватаю (всеми любимый ORA-600 - ошибка ядра).
DrPass (2006-07-05 11:10:00) [2]Тупые запросы на выборку (пусть даже не из aaa, а из десятка таблиц с разнообразными объединениями) - это в большинстве приложений 90% их работы. А до
> огромных косяков с дедлоками
дело не доходит. Ты же знаешь типичную схему работы с Interbase - одна постоянно открытая read-only транзакция и кратковременные транзакции записи. Приложения на ней обычно строятся так, что там просто нечему конфликтовать.
Андрей Пазик (2006-07-05 10:39:00) [3]Не, конечно если тупые запросы типа select * from aaa, то и IB 6.0 пойдет.
Однако в этого чуда огромные косяки с дедлоками, неоднозначности в результатах запросов и т.д. и т.п.
DrPass (2006-07-04 18:20:00) [4]
> Андрей Пазик (04.07.06 17:34) [23]
Баги там, может, и есть... но я, как запустил в 2002 году бек-офис в одной конторе на IB6, так он с тех пор и работает в режиме 24*7 и никаких ошибок, кроме сдохшего однажды винта. В любом случае, глюки СУБД - штука оччень специфическая, на них еще надо постараться попасть
Андрей Пазик (2006-07-04 17:34:00) [5]> это 5.5
> а шестерка нормальная
Ты только никому этого не говори :)
Количество багов, поправленных разработчиками Firebird в коде IB 6.0 исчисляется сотнями.
На sql.ru за использование IB 6.0 пожизненный растрел через повешение.
Desdechado (2006-07-04 10:52:00) [6]> Самая глючная версия.
это 5.5
а шестерка нормальная
atruhin (2006-07-04 08:07:00) [7]> Ты состоишь в секте противников Interbase 6?
А зачем состоять? Самая глючная версия.
DrPass (2006-07-03 01:48:00) [8]
> Андрей Пазик (02.07.06 23:04) [19]
Ты состоишь в секте противников Interbase 6?
Андрей Пазик (2006-07-02 23:04:00) [9]DmitrichJ (30.06.06 0:06)
Есть БД (InterBase 6)
Шел 2006 год, а партизаны все продолжали пускать под откос фашистские поезда. В какой глухомани вы живете?
ЮЮ (2006-07-01 06:30:00) [10]
> Допустим Петров взял запись на редактирование, и пока он
> изменяет данные в форме, Сидоров не мог бы редактировать
> эту запись.
>
> сижу блин и голову ломаю...
Cмотри
http://www.delphimaster.ru/cgi-bin/forum.pl?id=1151493853&n=1
и ссылки
DrPass (2006-07-01 01:41:00) [11]
> И что делать если юзер неккоректно выйдет из проги. Как
> записать в поле что он отключён???
Вот в частности поэтому и не придумывай никакой ерунды, а делай стандартными средствами, которые уже подсказали.
> И объясните мне, про технологический логин. Как физически
> писать прогу?
Что непонятно? Как залогиниться, получить список пользователей, отключиться и снова залогиниться под другим логином, что ли?
Виталий Панасенко (2006-06-30 22:47:00) [12]
> DmitrichJ (30.06.06 19:45) [15]
> И объясните мне, про технологический логин. Как физически
> писать прогу?
За тебя написать не нужно ?
DmitrichJ (2006-06-30 19:45:00) [13]И объясните мне, про технологический логин. Как физически писать прогу?
DmitrichJ (2006-06-30 19:43:00) [14]
> Тогды в чем вопрос ? коннекться под sysdba ( А технологический
> логин может где-то храниться в зашифрованном виде) к базе,
> создай там таблицу пользователей TB_USR, в которой можно
> будет хранить и русские имена пользователей, а также таблицу
> блокировок TB_LOCK, чтобы нельзя было подконнектиться дважды
> под одним аккаунтом.
> TB_LOCK будет хранить дату последнего обращения, а клиентская
> прога по таймеру пусть туда пишет записи, и при коннекте
> проверяй дату последнего обращения к базе. Если она больше
> интревала таймера умноженного на два - пускай в базу.
> Почему нельзя просто писать в какое либо поле подключен/неподключен
> при коннекте/дисконнекте - юзверь може прибить прогу через
> диспетчер задач и тогда больше никода в базу не попадет.
>
Вот именно так и я сразу решил сделать. Но думаю насколько хорошо будет запускать запросы на запись с 15 компов постоянно. И что делать если юзер неккоректно выйдет из проги. Как записать в поле что он отключён???
DmitrichJ (2006-06-30 19:38:00) [15]
> Т.е. ты хочешь сказать, что прога будет коннектиться с каким
> либо аккаунтом к security.fdb (isc4.gdb)с правами на чтение
> списка пользователей. А как она его знает ? Хранит в файле,
> реестре и т.д. ? Тоды на фиг вообще авторизация, коннекться
> под sysdba-masterkey, создай таблицу tb_users прямо в базе
> и храни там пароли, русские имена пользователей можно запихнуть.
> ..
Вообщето я это и имел ввиду, что список будет в самой базе, но чтобы начать работать с остальными данными, ножино типа зарегистрироваться. И есть ещё один интересный ньюанс. Допустим Петров взял запись на редактирование, и пока он изменяет данные в форме, Сидоров не мог бы редактировать эту запись.
сижу блин и голову ломаю...
Desdechado (2006-06-30 13:56:00) [16]PEAKTOP © (30.06.06 13:29) [10]
> коннекться под sysdba
Глупо. Ибо эта учетная запись имеет все права, а технологическому логину можно дать очень ограниченные. Да и пароль все равно где-то хранить надо, так лучше хранить ограниченный.
> Почему нельзя просто писать в какое либо поле подключен/неподключен
Именно поэтому лучше так не делать. Достаточно хранить имена пользователей и их логины. А проверить подключенность логина можно через специальные средства IB API, а не самопальщиной.
PEAKTOP (2006-06-30 13:33:00) [17]
> 2. Войдя под собой мог бы видеть кто сейчас работает с БД.
Ну а это через селект из TB_LOCK, где дата последнего обращения больше "текущая дата" минус ("интервала таймера" умнож. на два).
PEAKTOP (2006-06-30 13:29:00) [18]
> То лучше, чтоб юзеры не знали своих настоящих логинов-паролей в БД...
Тогды в чем вопрос ? коннекться под sysdba ( А технологический логин может где-то храниться в зашифрованном виде) к базе, создай там таблицу пользователей TB_USR, в которой можно будет хранить и русские имена пользователей, а также таблицу блокировок TB_LOCK, чтобы нельзя было подконнектиться дважды под одним аккаунтом.
TB_LOCK будет хранить дату последнего обращения, а клиентская прога по таймеру пусть туда пишет записи, и при коннекте проверяй дату последнего обращения к базе. Если она больше интревала таймера умноженного на два - пускай в базу.
Почему нельзя просто писать в какое либо поле подключен/неподключен при коннекте/дисконнекте - юзверь може прибить прогу через диспетчер задач и тогда больше никода в базу не попадет.
Desdechado (2006-06-30 12:09:00) [19]> прога будет коннектиться с каким либо аккаунтом к security.fdb
Я такого не говорил. Это служебная БД и к ней цепляться - дурной тон. Тем паче к ней в FB2 вообще запретили коннект.
А технологический логин может где-то храниться в зашифрованном виде.
> А если безопасность не по барабану
То лучше, чтоб юзеры не знали своих настоящих логинов-паролей в БД, а то особо вумные смогут посторонними средствами ходить в БД. Видел я такое.
PEAKTOP (2006-06-30 11:49:00) [20]
> Desdechado © (30.06.06 10:32) [5]
>
> DmitrichJ (30.06.06 00:59) [3]
> Чтобы прочитать список пользователей, нужно подключиться
> к БД. А чтобы подключиться к БД, нужно спросить логин-пароль.
> Если пользователь не вводит, а выбирает, значит, программа
> должна подключиться к БД заранее с каким-то специальным
> аккаунтом ("технологическим логином").
>
Т.е. ты хочешь сказать, что прога будет коннектиться с каким либо аккаунтом к security.fdb (isc4.gdb)с правами на чтение списка пользователей. А как она его знает ? Хранит в файле, реестре и т.д. ? Тоды на фиг вообще авторизация, коннекться под sysdba-masterkey, создай таблицу tb_users прямо в базе и храни там пароли, русские имена пользователей можно запихнуть...
А если безопасность не по барабану, то пусть юзеры логин-пароль сами каждый раз печатают (заодно и клавиатуру быстрей выучат), т.к. если есть список пользователей, то остается только подобрать пароль. Или найти, где храниться настройка подключения, считать оттудыва имя пользователя и пароль имеющего право на чтение списка пользователей из securty.fdb, а оттудва уже иметь пароль и sysdba в том числе.