Whel, maybe I'm blind... I've not noticed that was only the "prepare" statement, but I can't, in the SQLMonitor, see the actual second SQL, so...
Well, after the first prepare, at each edit SQLMonitor tells:
/*---
EXECUTE STATEMENT
TR_HANDLE = 13916292
STMT_HANDLE = 13911088
PARAMS = [ Version 1 SQLd 1 SQLn 1
CONTACT.ID[ID] = 1004 ]

SELECT COUNT: 1
UPDATE COUNT: 1
-----
a) is this the "dummy update lock" one? How can you tell this? (I really think so, but how be sure using the SQLMonitor?)
b) if I close the query, it goes in dssSearch, and the LockSQL statement is NOT unprepared (and if I then go to a record again and edit, not prepare statement is issued). Just curiosity, are you sure that sooner or later the statement is unprepared (and server resourced free)? If, instead of pressing the "query close" button, I go directly in search mode with the apropriate IB_SearchBar button, when I press "first" the query of the dataset is prepared again, but the lock one is not when I go to edit state again... is it normal?
Sorry for this sort of questions, but your answers help me a lot understand the "inner" of ibo and interbase.
regards
Marco Menardi

--- In IBObjects@y..., "Jason Wharton" <jwharton@i...> wrote:
> 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@l...>
> To: <IBObjects@y...>
> 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
> >