Hi Helen,

I have re-read the documentation associated to the Survey demo. I have also
followed the [Firebird-support] Avoiding pessimistic locking thread. Very
interesting and helpful.


What I am trying to achieve is very similar to what was mention in the
thread mention above i.e

User A edits record A
User B and or any other users attempts to edit record A

I would like the application/DB to:

1. Allow any and all user to read any record even if it currently being
update by some other user.

2. Stop record A from being edited by user B or any other user (for example
not allowing the dataset to get into edit mode)

3. Notify User B and any other user trying to edit record A that this record
is currently being edited by some other user.

4. If User A does not coming within a time period, release the lock on
record A

5. If User A commits within the allowed time period, notify all other users
Of the update, i.e automatically update the record they are viewing (which
is what the Survey Demo does).

Now, from what I have read in your book, the Survey demo doc and the thread
mention above, this can NOT be achieved automatically using a combination of
Isolation Rules (please correct me if I am wrong).

So from what I understand, I must create an "audit trail" which will allow
me to lock a record when User A begins an update process. If User B then
decides to update the same record the App will deny such right, as well as
notify her/him that the record is currently being updated by some other
User, etc.

In other words, follow what David Johnson said in the Avoiding pessimistic
Locking thread on Friday the 7th of October.


Would you agree with this? Or is there a better, more efficient, safer
procedure to follow?

Thanks

daniel

> Hi Helen,
>
> I will have another serious look at the Docs, Survey demo and Book and
> report back. But once more, thank you for the help.
>
> Daniel
>