Thank you for all advises.

> Perhaps you don't understand that pessimistic locking is unnatural to
> the way Firebird deals with transaction isolation. It has optimistic
> row-level locking on all reads. This means it does not lock anything
> until a request arrives to change a row. At that point, the changed
> row becomes unavailable for writes by any other transaction; but all
> of the unchanged rows can be accessed by other transactions.

If this true, why an error has occured when I've used a same SELECT
with "WITH LOCK" from other transaction? what does it mean about "it
does not lock anything until a request arrives to change a row"? when
Firebird will know the row is needed to change?

> You really must take notice of the warnings in the release notes
> about using WITH LOCK and never use it for SELECTs that return

multiple rows.

I've read this, it sound like WITH LOCK is useless. what's is the main
idea of Firebird's explicit lock? and it was designed for what?

Montri.