Hello, Sean!

"Leyne, Sean" wrote:

> > Also, perhaps the concept of 'disabling' user can be
> > added, as in alter user <username> [enable|disable];
>
> Interesting idea... not sure about the practical benefit

most systems that able to manage user access allow
not only to enable/disable user wihout affecting
user's access rights, but allow to configure day/time
access for that user.

> Actually, remember within the current FB design, Enable|Disable or
> (Active|Inactive as I would suggest) the user status is stored in the
> security database and applies to all databases -- so this would not be a
> good thing.

Yes, it will be good thing anyway. isc4.gdb is "server-centric"
user security management. Local database user security is
"database-centric". I know lot of companies that uses
only one of those security schema, and lot of that wants
these mixed. So, both systems must have same functionality.

For example, I have system with server and 10 users.
5 of that users must have access to 2 databases.
Other 5 users must have access to these 2 databases
and 2 other ones.

We can do that only having
1. 10 users in isc4.gdb/security.fdb
2. 5 users in 2 last menitioned database (like in IB 7.5).

> - what error message would they receive when they try to attach a
> database?

"user login/account is disabled", as usual.

--
Dmitri Kouzmenko

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/