It only needs to prepare the statement on the first one. It should have to
prepare it over and over again.
Look for the execution of that statement to indicate that a lock is
performed.
I suggest you also test functionality as a 'second witness' to your
situation and tell me what happens.

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@...>
To: <IBObjects@yahoogroups.com>
Sent: Friday, October 18, 2002 12:35 PM
Subject: [IBO] Re: PessimisticLook and only one dummy update for dataset:
bug?


> --- 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
>