Leyne, Sean wrote:

>> I thought that was what the security / authentication subsystem
>> was supposed to do.
>>
>
> In principle, yes.
>
> In practice, not always.
>
> First, currently users are defined for the server, not the database.
> Accordingly, a define user can connect to any database, and hold an open
> connection, whether they have rights to any db objects in the db.
>

Not so in Vulcan. A database may be configured to use *the* security,
*a* security database, or itself. Users are never defined "for the
server". Not even a concept.

Firebird2 and earlier did have a hardwired security database, but that
is now a legacy. So unless you're prepared to either rip the pluggable
security mechanism out of Vulcan or write off Vulcan, you need to adapt
to the security model going forward.

> Next, you have a database user "User1" which has rights, but you want to
> temporarily disable their access to a specific db.
>
>
>
>>> On begin transaction for implementation of a "writable
>>>
> transaction
>
>>> id" (incrementing a generator and storing in a context variable).
>>>
>> Don't we have a mechanism for creating transaction ids? Do we really
>> need two different ones - one of which uses a generator so it can be
>> bumped or reset?
>>
>
> The problem with the current transaction id is that it is reset with a
> database restore.
>

Why is this a problem? Transaction id is not something that anybody
should be saving.

> The generator approach ensures that the ID is unique across restores.
>
>

Do you have any idea of the mayhem that would result is somebody reset
the generator?

--

Jim Starkey, Senior Software Architect
MySQL AB, www.mysql.com
978 526-1376