--- In IBObjects@y..., "Jason Wharton" <jwharton@i...> wrote:

> It won't do a lock on a record unless you put it into edit state. Are you
> sure you are not expecting it to do something other than what it does?

As I stated, I put the first (or whatever) record of the grid in edit state, and SQLMonitor shows me the "lock sql" (like the automatically made UPDATE CUSTOMERS SET CUSTOMER_ID = CUSTOMER_ID
WHERE CUSTOMERS.CUSTOMER_ID = ? /* OLD.CUSTOMER_ID */), then I change record and put this other row in edit state. Then SQLMonitor does not show the above SQL code anymore.
Use your sample "Contact". Set PessimisticLook to true in the dmContact.qrContact, then run the program and File->Sql monitor.
Go to the record you like, i.e. pressing the "first" while in search mode. Clear the SQLmonitor and enter a character in one of the fields. At some point of the SQLmonitor you will read:
/*---
PREPARE STATEMENT
TR_HANDLE = 13916292
STMT_HANDLE = 13911088

UPDATE CONTACT SET ID = ID
WHERE CONTACT.ID = ? /* OLD.ID */

PLAN (CONTACT INDEX (RDB$PRIMARY2))
----

press "post", then go to the next record. Enter a character in a field, but now you will not have the above statement in the SQLMonitor! Seems that is done only once.

The question is:
a) only the first record is locked, the second not
b) all the record of the resoulting dataset are locked
c) the first AND the second record are locked

So a,b,c or IBO has a bug? Since with Intebase there is not a "lock" in the traditional way, but it's a trick linked with the transaction concept, there could be something I'm missing here...

Thanks
Marco Menardi

>
> Jason Wharton
> CPS - Mesa AZ
> http://www.ibobjects.com
>
> -- We may not have it all together --
> -- But together we have it all --
>
>
> ----- Original Message -----
> From: "Marco Menardi" <mmenaz@l...>
> To: <IBObjects@y...>
> Sent: Friday, October 18, 2002 4:08 AM
> Subject: [IBO] PessimisticLook and only one dummy update for dataset: bug?
>
>
> > During a debug of my app, I've discovered that in a dataset from IB_Query
> with pessimistic looking at true, when I start editing the first row of the
> grid the famous "lock dummy update" is performed, but when I then go to the
> second row and edit it, SQLMonitor does not show an update upon the new row
> anymore. Going through the code shows that the "lock process" is fired, but
> there is a certain condition that prevents it to be performed. The same with
> an explicit SQLLock or not.
> > Is it normal or a bug?
> > (BTW, how could I 'unlock' a row, after the editing is performed? Must I
> commit/rollback the transaction?)
> > thanks
> > IBO 4.2I, Firebird 1.0,
> > Transaction isolation: tiCommitted