At 10:35 AM 20/02/2004 +0000, you wrote:

>Im developing a multiuser aplication in IBO + FireBird
>
>Actually TWO user can edit SAME time SAME Record (Row), of course only
>one of them stay his values...
>
>But I need some way to DISABLE the second edition, by error, to not
>let changes simultaneous in same record...
>
>any idea?

Yes - on sets where you *really need* pessimistic lock, set the
PessimisticLocking property true. (You don't need a LockSQL statement
normally - that's just when you want to do something different from the
standard, which is update mytable set ThePrimaryKey=ThePrimaryKey).

"Really need" means you have a high contention system where different users
are hitting the same rows constantly. You never use table-level or
set-level locks in interactive environments.

Watch your BeforeUpdate, AfterUpdate, BeforeDelete and AfterDelete triggers
when using this. You will have to devise some way to avoid them firing
when the dummy update fires.

Even row-level pess. locking is *not* the coolest way to run a multi-user
system. Better to avoid it and use explicit (start transaction yourself)
ReadCommitted transactions in WAIT mode true, RecVersion False and
hard-commit them explicitly immediately after posting. Handle the rare
version conflict with a good exception handler.

That way, the server will queue the requests.

Helen