Jim Starkey wrote:

> 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?
>

The "writable transaction id" that I said is a *user* thing.

Could be used to group operations done in the same transaction or
connection, in a log, for example.
They should be maintained after a restore, one could not use the engine
transaction id.

Credits for problems when anyone reset the generator should go for who
reset and/or for who designed it to be resettable.


Adriano