At 05:15 AM 15/09/2006, you wrote:

>I'm trying to determine, if a row is already locked by pessimistic
>locking from
>another workstation or application.
>But it is does not return "true" on a locked record

IsRowLocked will return True if YOUR application has a pending update
or delete on it.

> and as soon as I switch the
>query into editmode by ib_query.edit the exception
>EIB_DatasetError.Create( '[' + Name + '] ' + E_Record_Locked )" is
>triggered.

Correct, if you have set PessimisticLocking true. That is because
YOUR application will attempt to perform a dummy update. If another
transaction already has a pending update (incl. a pessimistic lock)
on that row, it will not be possible for your transaction to do so.

So, there lies your mechanism for determining whether "a row is
already locked from another workstation or application" or, more
precisely, from another *transaction*. Catch the exception and
inform the user why s/he can't go into edit mode at this stage.

There is of course no way to know whether the other transaction has
acquired the lock through pess. locking or some other form of
update. Firebird and IB are optimistic locking.

>Is there something else I have to have in mind using "isrowlocked"?

Use it when you want to check whether the user has *already* started
to edit the record (with PessimisticLocking true) or has already
posted an update or delete of this record to the server (with or
without P.L.) in the same transaction that is yet uncommitted.

Helen